Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #130163 > unrolled thread

Re: [Solved] Need some help getting to my feet

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Solved] Need some help getting to my feet Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-05-04 13:31 +0000
    Re: [Solved] Need some help getting to my feet luser droog <luser.droog@gmail.com> - 2018-05-04 17:19 -0700
    Re: [Solved] Need some help getting to my feet Tim Rentsch <txr@alumni.caltech.edu> - 2018-05-18 21:55 -0700
      Re: [Solved] Need some help getting to my feet already5chosen@yahoo.com - 2018-05-21 03:26 -0700
        Re: [Solved] Need some help getting to my feet Tim Rentsch <txr@alumni.caltech.edu> - 2018-06-14 03:00 -0700
          Mixing declarations and statements in C code (Was: [Solved] Need some help getting to my feet) gazelle@shell.xmission.com (Kenny McCormack) - 2018-12-26 06:43 +0000
        Re: [Solved] Need some help getting to my feet Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-12-26 19:02 +0300
          Re: [Solved] Need some help getting to my feet Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-31 18:01 +0000
          Re: [Solved] Need some help getting to my feet Richard Damon <Richard@Damon-Family.org> - 2018-12-31 17:16 -0500
            Re: [Solved] Need some help getting to my feet Bart <bc@freeuk.com> - 2018-12-31 22:44 +0000
              Re: [Solved] Need some help getting to my feet Ike Naar <ike@iceland.freeshell.org> - 2019-01-01 19:14 +0000
                Re: [Solved] Need some help getting to my feet rbowman <bowman@montana.com> - 2019-01-01 13:14 -0700
                  Re: [Solved] Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2019-01-01 12:49 -0800
                    Re: [Solved] Need some help getting to my feet rbowman <bowman@montana.com> - 2019-01-01 15:55 -0700
                      Re: [Solved] Need some help getting to my feet Keith Thompson <kst-u@mib.org> - 2019-01-01 16:05 -0800
                        Re: [Solved] Need some help getting to my feet rbowman <bowman@montana.com> - 2019-01-01 22:17 -0700
                Re: [Solved] Need some help getting to my feet Bart <bc@freeuk.com> - 2019-01-01 20:25 +0000

#130163 — Re: [Solved] Need some help getting to my feet

On Fri, 2018-04-27, Keith Thompson wrote:
...
> In my opinion, you can get a good start learning the language from K&R2
> (if you have some existing programming experience).  You can pick up the
> changes made by C99 and C11 later on.

IMO, there are some C99 features you want to use from the very start:

- Declarations aren't limited to the beginning of the block (so you
  can use const more, and you're not punished for introducing
  temporaries for readability).

- Inline functions (so you can put code in header files, and are less
  tempted to write long macros).

They affect the structure of your code more than some other C99
additions.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [next] | [standalone]

#130220

On Friday, May 4, 2018 at 8:32:02 AM UTC-5, Jorgen Grahn wrote:
> On Fri, 2018-04-27, Keith Thompson wrote:
> ...
> > In my opinion, you can get a good start learning the language from K&R2
> > (if you have some existing programming experience).  You can pick up the
> > changes made by C99 and C11 later on.
> 
> IMO, there are some C99 features you want to use from the very start:
> 
> - Declarations aren't limited to the beginning of the block (so you
>   can use const more, and you're not punished for introducing
>   temporaries for readability).
> 
> - Inline functions (so you can put code in header files, and are less
>   tempted to write long macros).
> 
> They affect the structure of your code more than some other C99
> additions.
> 

Agree. But I'd add a few more to the list. I /love/ compound literals
and designated initializers. 

Compound literals let you create struct and union and other complicated
objects in the middle of expressions. Often this can eliminate the need
for a variable and simplify the function overall (nb. I said 'often' not
'always'). Esp, things like a string literal of wchar_t or some other
exotic character type.

Designated initializers let you specify which member gets the value. 
For unions, it's a total life safer. For structs, it's still super 
nice. And for things like sparse arrays, fuggetaboutit. Hands down,
flat out, double plus good.

Coupled with a macro, I've used these recently for a super-quick and 
super-dirty object-oriented style.


typedef struct parser *parser;
typedef struct result *result;
typedef result (*handler)( parser p, char *input );


/* A parser is a tree whose leaves are parse_term(), parse_fail(),                                                                                                                                                                
   and parse_succeed() nodes. */
struct parser {
  handler test;
  parser a, b;
  int c;
};

/* A parser returns a list of results. A NULL pointer indicates                                                                                                                                                                   
   no results, ie. failure. */
struct result {
  result next;
  int length_matched;
};

#define new_function_for_(type) \
  type new_##type ( struct type input ){ \
    type local = calloc( sizeof *local, 1 ); \
    return  local  ?  ( *local = input ), local  :  local; \
  }
new_function_for_(parser)
new_function_for_(result)


If you have this kind of setup, then the designated initializers
can be used like named parameters in calls to the new* functions.

 new_result( (struct result){ .next = NULL, .length_matched = 0 } );

 new_parser( (struct parser){ .test = parse_fail } );

 new_parser( (struct parser){ .test = parse_term, .c = c } );


Code from the clc post "Re: Parser Combinators" 6/16/17
https://groups.google.com/d/msg/comp.lang.c/BuwBXfpgN_M/4I4krY2PAgAJ
https://groups.google.com/d/topic/comp.lang.c/BuwBXfpgN_M/discussion
follow-ups to:
https://codereview.stackexchange.com/questions/166009/parser-combinators-in-oo-c

[toc] | [prev] | [next] | [standalone]

#130794

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Fri, 2018-04-27, Keith Thompson wrote:
> ...
>
>> In my opinion, you can get a good start learning the language from K&R2
>> (if you have some existing programming experience).  You can pick up the
>> changes made by C99 and C11 later on.
>
> IMO, there are some C99 features you want to use from the very start:
>
> - Declarations aren't limited to the beginning of the block (so you
>   can use const more, and you're not punished for introducing
>   temporaries for readability).
>
> - Inline functions (so you can put code in header files, and are less
>   tempted to write long macros).
>
> They affect the structure of your code more than some other C99
> additions.

These surprise me because neither is either necessary or important.
Functions in header files can be written as just regular static
functions and typically they will be inlined anyway (and worrying
about whether they are inlined is usually premature optimization).
The idea that mixing declarations and statements adds a lot sounds
like C++ bias (where using const initialization frequently has
semantic implications, unlike C).  Besides if it's important, just
put in a new compound statement.

There must be at least a dozen language features introduced in C99
that are more important than these two.  Better to not even put
these on the list, and emphasize writing short functions without
falling into the trap of premature optimization.

[toc] | [prev] | [next] | [standalone]

#130915

On Saturday, May 19, 2018 at 7:56:09 AM UTC+3, Tim Rentsch wrote:
> 
> The idea that mixing declarations and statements adds a lot sounds
> like C++ bias (where using const initialization frequently has
> semantic implications, unlike C).
>

The idea that mixing declarations and statements does not add a lot sounds like Torvaldsian bias.

[toc] | [prev] | [next] | [standalone]

#131630

already5chosen@yahoo.com writes:

> On Saturday, May 19, 2018 at 7:56:09 AM UTC+3, Tim Rentsch wrote:
>
>> The idea that mixing declarations and statements adds a lot sounds
>> like C++ bias (where using const initialization frequently has
>> semantic implications, unlike C).
>
> The idea that mixing declarations and statements does not add a
> lot sounds like Torvaldsian bias.

Then apparently you have misunderstood my comment.  I'm not
opposed to mixing declarations and statements, in cases
where it adds value.  I'm not dogmatic about it either way.

[toc] | [prev] | [next] | [standalone]

#139076 — Mixing declarations and statements in C code (Was: [Solved] Need some help getting to my feet)

In article <kfn1sd9g015.fsf@x-alumni2.alumni.caltech.edu>,
Tim Rentsch  <txr@alumni.caltech.edu> wrote:
>already5chosen@yahoo.com writes:
>
>> On Saturday, May 19, 2018 at 7:56:09 AM UTC+3, Tim Rentsch wrote:
>>
>>> The idea that mixing declarations and statements adds a lot sounds
>>> like C++ bias (where using const initialization frequently has
>>> semantic implications, unlike C).
>>
>> The idea that mixing declarations and statements does not add a
>> lot sounds like Torvaldsian bias.
>
>Then apparently you have misunderstood my comment.  I'm not
>opposed to mixing declarations and statements, in cases
>where it adds value.  I'm not dogmatic about it either way.

I think that it changes the flavor and look of C programs.  It makes C
look more like some new-ish thing - like we might see from MS or Sun or
some company like that - rather than the gritty, low-level, assembler-like
language that we all grew up with.

I've gotten used to it (*) and kinda like it in my code, but again I do
have to admit that it gives it a kinda new-age look.

(*) Not that it is in reality some newfangled thing.  It's been in the
standard for 19 years, and allowable in gcc (the only compiler I use) for
quite a while before that.

P.S.  It'd be interesting to know exactly *WHY* Linus don't like it...

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/BestCLCPostEver

[toc] | [prev] | [next] | [standalone]

#139083

already5chosen to Tim Rentsch:

>>The idea that mixing declarations and statements adds a
>>lot sounds like C++ bias (where using const initialization
>>frequently has semantic implications, unlike C).
>
>The idea that mixing declarations and statements does not
>add a lot sounds like Torvaldsian bias.

I prefer the old style because it better reflext the way I
think of an algorithm: declare me some variables and then
work with them.  There are two benefits:

  1.  When a function grows so large that scrolling up to
      the declaration sections becomes annoying, it is a
      sure sign a refactoring is due.  And it is a good
      style that lets code plead the developer: "Refactor
      me!".

  2.  Code flows smoother and has better rhythm.  Actions
      are not interrupted by declarations.  Actions are
      separate from declarations.

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#139290

On Wed, 2018-12-26, Anton Shepelev wrote:
> already5chosen to Tim Rentsch:
>
>>>The idea that mixing declarations and statements adds a
>>>lot sounds like C++ bias (where using const initialization
>>>frequently has semantic implications, unlike C).
>>
>>The idea that mixing declarations and statements does not
>>add a lot sounds like Torvaldsian bias.

I'm not going to change anyone's mind after two decades, but some
comments anyway:

> I prefer the old style because it better reflext the way I
> think of an algorithm: declare me some variables and then
> work with them.

That's tautological. You cannot change the way you write your code
without changing the way you think, and the change in thinking is the
whole point.  I once did locals the C89 way, but moved to C99 and
adjusted. I think it was an improvement -- not only because I write a
lot of C++ too.

> There are two benefits:
>
>   1.  When a function grows so large that scrolling up to
>       the declaration sections becomes annoying, it is a
>       sure sign a refactoring is due.  And it is a good
>       style that lets code plead the developer: "Refactor
>       me!".

I dislike that argument, which pops up now and then (not just with C99
declarations). It's about making something worse on purpose, so you're
forced to deal with it.

I'd rather have a mild problem which I /don't/ have to deal with, so I
can deal with all the other problems instead.

>   2.  Code flows smoother and has better rhythm.  Actions
>       are not interrupted by declarations.  Actions are
>       separate from declarations.

See above: that's the way you think about it now, but to me it's a
meaningless distinction.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#139305

On 12/26/18 11:02 AM, Anton Shepelev wrote:
> already5chosen to Tim Rentsch:
> 
>>> The idea that mixing declarations and statements adds a
>>> lot sounds like C++ bias (where using const initialization
>>> frequently has semantic implications, unlike C).
>>
>> The idea that mixing declarations and statements does not
>> add a lot sounds like Torvaldsian bias.
> 
> I prefer the old style because it better reflext the way I
> think of an algorithm: declare me some variables and then
> work with them.  There are two benefits:
> 
>   1.  When a function grows so large that scrolling up to
>       the declaration sections becomes annoying, it is a
>       sure sign a refactoring is due.  And it is a good
>       style that lets code plead the developer: "Refactor
>       me!".
> 
>   2.  Code flows smoother and has better rhythm.  Actions
>       are not interrupted by declarations.  Actions are
>       separate from declarations.
> 

In my view, the declaration doesn't break the flow of the action, but is
just part of the action of declaring the variable as it is being
initialized.

  float dist = fsqrt(x*x + y*y);

The float isn't that distracting or interrupting (and putting them
together makes the function shorter).

Now, if you are creating a structure and needing to initialize all the
pieces with separate statements, then you need a separate declaration
statement, but you can initialize perhaps a lot of the structure in that
statement.

[toc] | [prev] | [next] | [standalone]

#139307

On 31/12/2018 22:16, Richard Damon wrote:
> On 12/26/18 11:02 AM, Anton Shepelev wrote:
>> already5chosen to Tim Rentsch:
>>
>>>> The idea that mixing declarations and statements adds a
>>>> lot sounds like C++ bias (where using const initialization
>>>> frequently has semantic implications, unlike C).
>>>
>>> The idea that mixing declarations and statements does not
>>> add a lot sounds like Torvaldsian bias.
>>
>> I prefer the old style because it better reflext the way I
>> think of an algorithm: declare me some variables and then
>> work with them.  There are two benefits:
>>
>>    1.  When a function grows so large that scrolling up to
>>        the declaration sections becomes annoying, it is a
>>        sure sign a refactoring is due.  And it is a good
>>        style that lets code plead the developer: "Refactor
>>        me!".
>>
>>    2.  Code flows smoother and has better rhythm.  Actions
>>        are not interrupted by declarations.  Actions are
>>        separate from declarations.
>>
> 
> In my view, the declaration doesn't break the flow of the action, but is
> just part of the action of declaring the variable as it is being
> initialized.
> 
>    float dist = fsqrt(x*x + y*y);
> 
> The float isn't that distracting or interrupting (and putting them
> together makes the function shorter).
> 
> Now, if you are creating a structure and needing to initialize all the
> pieces with separate statements, then you need a separate declaration
> statement, but you can initialize perhaps a lot of the structure in that
> statement.
> 


I have the opposite view. Not only do I like all declarations separate 
(and tidily tucked away at the top of a function, not even at the top of 
this block), but I like them to be only declarations, not also 
initialisations. (Except for array/struct initialisation.)

There are quite a few issues with having declarations scattered 
anywhere, such as having to locate the declaration for name (which will 
involve scanning every line backwards to the top of a function).

Or code mods which require a change in scope of variable so that its 
declaration needs to be moved (especially if you always want to smallest 
possible scope).

When there is a group of related variables, it is better to declare them 
together, as this gives useful information, compared with declaring each 
at first use.

But mainly, it just spoils the lines of the code. What the executable 
code does is one thing, the metadata about the types of the variables 
involved is another.

(In my two main languages which have the same syntax, one requires 
static type declarations, the other doesn't. Porting between the two is 
easier when the declarations are out of the way.)

-- 
bart

[toc] | [prev] | [next] | [standalone]

#139327

On 2018-12-31, Bart <bc@freeuk.com> wrote:
> There are quite a few issues with having declarations scattered 
> anywhere, such as having to locate the declaration for name (which will 
> involve scanning every line backwards to the top of a function).

Often those declarations are not "scatterd anywhere", they are
just a few lines above the point where the name is used so
there is no need to scroll back to the top of the function.

[toc] | [prev] | [next] | [standalone]

#139329

On 01/01/2019 12:14 PM, Ike Naar wrote:
> On 2018-12-31, Bart <bc@freeuk.com> wrote:
>> There are quite a few issues with having declarations scattered
>> anywhere, such as having to locate the declaration for name (which will
>> involve scanning every line backwards to the top of a function).
>
> Often those declarations are not "scatterd anywhere", they are
> just a few lines above the point where the name is used so
> there is no need to scroll back to the top of the function.
>

At times when I'm modifying existing code I will put the new 
declarations in the block where they are used. It's a signal to future 
maintenance programmers that the block wasn't original functionality and 
was added for some reason. We use Subversion so they can easily do 'svn 
blame' to find the bug reference.

[toc] | [prev] | [next] | [standalone]

#139334

rbowman <bowman@montana.com> writes:
> On 01/01/2019 12:14 PM, Ike Naar wrote:
>> On 2018-12-31, Bart <bc@freeuk.com> wrote:
>>> There are quite a few issues with having declarations scattered
>>> anywhere, such as having to locate the declaration for name (which will
>>> involve scanning every line backwards to the top of a function).
>>
>> Often those declarations are not "scatterd anywhere", they are
>> just a few lines above the point where the name is used so
>> there is no need to scroll back to the top of the function.
>
> At times when I'm modifying existing code I will put the new 
> declarations in the block where they are used. It's a signal to future 
> maintenance programmers that the block wasn't original functionality and 
> was added for some reason. We use Subversion so they can easily do 'svn 
> blame' to find the bug reference.

I don't see how that signals that the code was added later.  Why wouldn't
it have been written that way in the first place?

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#139338

On 01/01/2019 01:49 PM, Keith Thompson wrote:
> rbowman <bowman@montana.com> writes:
>> On 01/01/2019 12:14 PM, Ike Naar wrote:
>>> On 2018-12-31, Bart <bc@freeuk.com> wrote:
>>>> There are quite a few issues with having declarations scattered
>>>> anywhere, such as having to locate the declaration for name (which will
>>>> involve scanning every line backwards to the top of a function).
>>>
>>> Often those declarations are not "scatterd anywhere", they are
>>> just a few lines above the point where the name is used so
>>> there is no need to scroll back to the top of the function.
>>
>> At times when I'm modifying existing code I will put the new
>> declarations in the block where they are used. It's a signal to future
>> maintenance programmers that the block wasn't original functionality and
>> was added for some reason. We use Subversion so they can easily do 'svn
>> blame' to find the bug reference.
>
> I don't see how that signals that the code was added later.  Why wouldn't
> it have been written that way in the first place?
>

Because it wasn't :) I'll admit it is a special case but we have several 
hundred thousand lines of code going back over 20 years. The convention 
was, and still is for new functions, to declare all variables at the top 
of a function. A block with variable declarations stands out.

Obviously it would be meaningless if the stylistic convention was to 
declare variables in the blocks.

The arguments one way or the other do seem a little weak. I use Vim so 
if a variable suddenly appears # tracks it down pretty rapidly.

Again a special case and not C, but I chiefly use C++ with ESRI 
ArcObjects. It's COM based, depends heavily on smart pointers for 
interfaces, and tends to be verbose. Declaring the smart pointer at the 
point where you're going to magically say something like 'pFWS = pWS;' 
helps.

What I'm really saying is do what makes sense in the particular instance 
rather than saying 'Thou shalt declare all variables at the top.'

If I were writing the commandments there would be a 'Thou Shalt Not 
write 'float a, b, c, d, *e ,f ....'  That is as good a way to hide the 
variable you're looking for as any.

[toc] | [prev] | [next] | [standalone]

#139342

rbowman <bowman@montana.com> writes:
[...]
> The arguments one way or the other do seem a little weak. I use Vim so 
> if a variable suddenly appears # tracks it down pretty rapidly.
[...]

vim's "#" command jumps backward to the nearest occurrence of the
current word.

"gd" jumps directly to its declaration.  It doesn't always work
perfectly, but it's very useful when it does.

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#139352

On 01/01/2019 05:05 PM, Keith Thompson wrote:
> "gd" jumps directly to its declaration.  It doesn't always work
> perfectly, but it's very useful when it does.

I'll have to try that. Usually I find the variable fairly fast going 
backwards or use the square bracket to get to the head of the function 
and N to search forward if it's a heavily used variable.

There are a lot of Vim tricks and I've gotten used to a subset over the 
years. I should make a new year's resolution to learn some of the 
alternatives.

[toc] | [prev] | [next] | [standalone]

#139332

On 01/01/2019 19:14, Ike Naar wrote:
> On 2018-12-31, Bart <bc@freeuk.com> wrote:
>> There are quite a few issues with having declarations scattered
>> anywhere, such as having to locate the declaration for name (which will
>> involve scanning every line backwards to the top of a function).
> 
> Often those declarations are not "scatterd anywhere", they are
> just a few lines above the point where the name is used so
> there is no need to scroll back to the top of the function.

'Where the name is used' may span dozens of lines. So you need to search 
backwards from where you first see it. And a name might have 
function-wide scope so is declared at the top, but you don't know that 
(even if you glance at the top and see it there because they could be a 
more local declaration), so you still have to check every line, working 
backwards.

It can also happen there are two variables with similar names (call them 
a3947 and a3497 here); you see a3947 being used, glance at the top, and 
see a3497 being declared with no other likely variables in sight. It is 
easy to assume that that is the variable declaration you want.

(Have a look at the 219Kloc source of the amalgamated sqlite3 project, 
which mixes names declared at the top, with names declared within the 
code (not so much, just enough that you HAVE to carefully double-check) 
as well as some very confusing names plus, sometimes, the same name 
reused within different scopes in a function.)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web