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

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

comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2)

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

Contents

  comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Test <test@.nil.invalid.com> - 2012-12-15 15:47 +0200
    Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-15 14:05 +0000
      Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-15 20:26 +0000
        Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-15 20:47 +0000
          Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Les Cargill <lcargill99@comcast.com> - 2012-12-15 15:34 -0600
            Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-12-16 03:23 -0800
          Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Shao Miller <sha0.miller@gmail.com> - 2012-12-15 16:37 -0500
            Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-15 22:10 +0000
              Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Shao Miller <sha0.miller@gmail.com> - 2012-12-15 17:32 -0500
                Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Keith Thompson <kst-u@mib.org> - 2012-12-15 15:43 -0800
                  Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Shao Miller <sha0.miller@gmail.com> - 2012-12-16 02:15 -0500
                    Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Keith Thompson <kst-u@mib.org> - 2012-12-16 14:21 -0800
                      Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Shao Miller <sha0.miller@gmail.com> - 2012-12-16 18:34 -0500
                  Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 01:15 -0800
                    Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Keith Thompson <kst-u@mib.org> - 2012-12-17 10:30 -0800
                      Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) pete <pfiland@mindspring.com> - 2012-12-17 16:07 -0500
                  Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) pete <pfiland@mindspring.com> - 2012-12-17 08:13 -0500
                    Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Keith Thompson <kst-u@mib.org> - 2012-12-17 10:33 -0800
                Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-16 01:24 +0000
                  Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Shao Miller <sha0.miller@gmail.com> - 2012-12-16 02:19 -0500
                    Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-16 13:11 +0000
                      Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Shao Miller <sha0.miller@gmail.com> - 2012-12-16 14:51 -0500
                        Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-16 21:16 +0000
                      Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 00:55 -0800
                        Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-17 15:08 +0000
                          Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-20 10:40 -0800
          Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-15 22:09 +0000
    Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-12-15 06:11 -0800
      Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Les Cargill <lcargill99@comcast.com> - 2012-12-15 13:26 -0600
    Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) James Kuyper <jameskuyper@verizon.net> - 2012-12-15 09:24 -0500
      Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Keith Thompson <kst-u@mib.org> - 2012-12-15 12:21 -0800
        Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) James Kuyper <jameskuyper@verizon.net> - 2012-12-15 16:42 -0500
        Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Philip Lantz <prl@canterey.us> - 2012-12-16 00:09 -0800
          Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) James Kuyper <jameskuyper@verizon.net> - 2012-12-16 08:46 -0500
            Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Keith Thompson <kst-u@mib.org> - 2012-12-16 14:29 -0800
    Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) pete <pfiland@mindspring.com> - 2012-12-16 10:30 -0500
    Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-12-17 12:42 +0200
      Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-12-17 23:07 +0200
        Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) pete <pfiland@mindspring.com> - 2012-12-17 19:31 -0500
          Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-18 01:32 +0000
            Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) pete <pfiland@mindspring.com> - 2012-12-17 20:53 -0500
              Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-18 02:29 +0000
                Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) pete <pfiland@mindspring.com> - 2012-12-18 05:48 -0500
                  Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-18 11:26 +0000
                    Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) pete <pfiland@mindspring.com> - 2012-12-20 16:20 -0500
                  Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Keith Thompson <kst-u@mib.org> - 2012-12-18 03:44 -0800
              Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) James Kuyper <jameskuyper@verizon.net> - 2012-12-17 22:13 -0500
                Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) pete <pfiland@mindspring.com> - 2012-12-18 05:40 -0500
          Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-12-20 15:14 +0200
            Re: comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2) pete <pfiland@mindspring.com> - 2012-12-20 16:31 -0500

Page 1 of 3  [1] 2 3  Next page →

#29275 — comma in a c statement, ie for(i=0,i2=0;i<10;i++,i2)

I have:

for (i=0,i2=0;i<10;i++,i2++)
   {
   .. some code
   }

Is "," (comma) oke here?

I am converting below code to for -loop:

i=0;
i2=0;
while (i<10)
   {
   ... some code
   i++;
   i2++;
   }

Which is executed first in for (i=0,i2=0;i<10;i++,i2++)? i2=0 or i=0?

Any caveats? I could not find explanation to comma usage (maybe not not looking
hard enough).

[toc] | [next] | [standalone]

#29277

Test <test@.nil.invalid.com> writes:

> I have:
>
> for (i=0,i2=0;i<10;i++,i2++)
>    {
>    .. some code
>    }
>
> Is "," (comma) oke here?

Yes, though it's not obvious why you need both i and i2..  A few spaces
might be a good idea, though:

  for (i = 0, i2 = 0; i < 10; i++, i2++)

> I am converting below code to for -loop:
>
> i=0;
> i2=0;
> while (i<10)
>    {
>    ... some code
>    i++;
>    i2++;
>    }

How odd.  What's the point of have both i and i2?  If either gets
altered in the "some code" part then there is an argument for not
re-writing it as a "for" loop.  Generally, readers will expect the
variables mentioned in a "for" loops to be left alone in the body.  This
is not rule of the language but it's a good rule of thumb.

Note, also, that your "for" loop will not be the same as the "while"
loop if the while loop uses "continue".

> Which is executed first in for (i=0,i2=0;i<10;i++,i2++)? i2=0 or i=0?

i = 0.

> Any caveats? I could not find explanation to comma usage (maybe not
> not looking hard enough).

It is often considered a little confusing since the comma token has lots
of uses in C.

-- 
Ben.

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

#29287

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

(snip)

> How odd.  What's the point of have both i and i2?  If either gets
> altered in the "some code" part then there is an argument for not
> re-writing it as a "for" loop.  Generally, readers will expect the
> variables mentioned in a "for" loops to be left alone in the body.  This
> is not rule of the language but it's a good rule of thumb.

I have used "for" loops where I needed "continue" to restart
the loop without incrementing the index.

Otherwise, I agree.

-- glen

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

#29288

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
> (snip)
>
>> How odd.  What's the point of have both i and i2?  If either gets
>> altered in the "some code" part then there is an argument for not
>> re-writing it as a "for" loop.  Generally, readers will expect the
>> variables mentioned in a "for" loops to be left alone in the body.  This
>> is not rule of the language but it's a good rule of thumb.
>
> I have used "for" loops where I needed "continue" to restart
> the loop without incrementing the index.
>
> Otherwise, I agree.

So when you want that behaviour you'd write:

  for (<initialise>; <condition>;) {
    <code that uses continue>
    <increment>
  }

rather than

  <initialise>
  while (<condition>) {
    <code that uses continue>
    <increment>
  }

?  I don't think I would (and I could make hand-waving arguments about
why I wouldn't) but it's really just a matter to taste.

-- 
Ben.

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

#29290

Ben Bacarisse wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>
>> (snip)
>>
>>> How odd.  What's the point of have both i and i2?  If either gets
>>> altered in the "some code" part then there is an argument for not
>>> re-writing it as a "for" loop.  Generally, readers will expect the
>>> variables mentioned in a "for" loops to be left alone in the body.  This
>>> is not rule of the language but it's a good rule of thumb.
>>
>> I have used "for" loops where I needed "continue" to restart
>> the loop without incrementing the index.
>>
>> Otherwise, I agree.
>
> So when you want that behaviour you'd write:
>
>    for (<initialise>; <condition>;) {
>      <code that uses continue>
>      <increment>
>    }
>
> rather than
>
>    <initialise>
>    while (<condition>) {
>      <code that uses continue>
>      <increment>
>    }
>
> ?  I don't think I would (and I could make hand-waving arguments about
> why I wouldn't) but it's really just a matter to taste.
>


As soon as you need a break or continue in the for loop, my
heuristic is to go with a while. But I'm not always consistent
about it...

--
Les Cargill

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

#29322

On Dec 15, 9:34 pm, Les Cargill <lcargil...@comcast.com> wrote:
> Ben Bacarisse wrote:
> > glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
>
> >> Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> >> (snip)
>
> >>> How odd.  What's the point of have both i and i2?  If either gets
> >>> altered in the "some code" part then there is an argument for not
> >>> re-writing it as a "for" loop.  Generally, readers will expect the
> >>> variables mentioned in a "for" loops to be left alone in the body.  This
> >>> is not rule of the language but it's a good rule of thumb.
>
> >> I have used "for" loops where I needed "continue" to restart
> >> the loop without incrementing the index.
>
> >> Otherwise, I agree.
>
> > So when you want that behaviour you'd write:
>
> >    for (<initialise>; <condition>;) {
> >      <code that uses continue>
> >      <increment>
> >    }
>
> > rather than
>
> >    <initialise>
> >    while (<condition>) {
> >      <code that uses continue>
> >      <increment>
> >    }
>
> > ?  I don't think I would (and I could make hand-waving arguments about
> > why I wouldn't) but it's really just a matter to taste.
>
> As soon as you need a break or continue in the for loop, my
> heuristic is to go with a while. But I'm not always consistent
> about it...

I use these to signal intent. for (i= 0; i < 10; i++) signals that
it's an "ordinary" loop that executes 10 times.

while(x > 10) signals something a bit more complicated is going on

and for(;;) indicates something rather tricksy probably involving a
break (and I'll often put a distinctive comment in at the break).

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

#29291

On 12/15/2012 15:47, Ben Bacarisse wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>
>> (snip)
>>
>>> How odd.  What's the point of have both i and i2?  If either gets
>>> altered in the "some code" part then there is an argument for not
>>> re-writing it as a "for" loop.  Generally, readers will expect the
>>> variables mentioned in a "for" loops to be left alone in the body.  This
>>> is not rule of the language but it's a good rule of thumb.
>>
>> I have used "for" loops where I needed "continue" to restart
>> the loop without incrementing the index.
>>
>> Otherwise, I agree.
>
> So when you want that behaviour you'd write:
>
>    for (<initialise>; <condition>;) {
>      <code that uses continue>
>      <increment>
>    }
>
> rather than
>
>    <initialise>
>    while (<condition>) {
>      <code that uses continue>
>      <increment>
>    }
>
> ?  I don't think I would (and I could make hand-waving arguments about
> why I wouldn't) but it's really just a matter to taste.
>

It can also be a matter of lifetime (for C >= C99), which could 
potentially impact memory usage.  By using declarations (but not 
compound literals) in the 'for', such objects needn't've storage for the 
enclosing block.

- Shao Miller

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

#29294

Shao Miller <sha0.miller@gmail.com> writes:

> On 12/15/2012 15:47, Ben Bacarisse wrote:
>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>
>>> (snip)
>>>
>>>> How odd.  What's the point of have both i and i2?  If either gets
>>>> altered in the "some code" part then there is an argument for not
>>>> re-writing it as a "for" loop.  Generally, readers will expect the
>>>> variables mentioned in a "for" loops to be left alone in the body.  This
>>>> is not rule of the language but it's a good rule of thumb.
>>>
>>> I have used "for" loops where I needed "continue" to restart
>>> the loop without incrementing the index.
>>>
>>> Otherwise, I agree.
>>
>> So when you want that behaviour you'd write:
>>
>>    for (<initialise>; <condition>;) {
>>      <code that uses continue>
>>      <increment>
>>    }
>>
>> rather than
>>
>>    <initialise>
>>    while (<condition>) {
>>      <code that uses continue>
>>      <increment>
>>    }
>>
>> ?  I don't think I would (and I could make hand-waving arguments about
>> why I wouldn't) but it's really just a matter to taste.
>>
>
> It can also be a matter of lifetime (for C >= C99), which could
> potentially impact memory usage.  By using declarations (but not
> compound literals) in the 'for', such objects needn't've storage for
> the enclosing block.

That does not match my understanding.  Can you provide supporting
evidence?

Putting a declaration in a for statement (as opposed to just before a
while) alters the scope the scope of the name but does not, I think,
have any effect on the lifetime of the declared object.

-- 
Ben.

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

#29295

On 12/15/2012 17:10, Ben Bacarisse wrote:
> Shao Miller <sha0.miller@gmail.com> writes:
>
>> On 12/15/2012 15:47, Ben Bacarisse wrote:
>>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>>
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>>
>>>> (snip)
>>>>
>>>>> How odd.  What's the point of have both i and i2?  If either gets
>>>>> altered in the "some code" part then there is an argument for not
>>>>> re-writing it as a "for" loop.  Generally, readers will expect the
>>>>> variables mentioned in a "for" loops to be left alone in the body.  This
>>>>> is not rule of the language but it's a good rule of thumb.
>>>>
>>>> I have used "for" loops where I needed "continue" to restart
>>>> the loop without incrementing the index.
>>>>
>>>> Otherwise, I agree.
>>>
>>> So when you want that behaviour you'd write:
>>>
>>>     for (<initialise>; <condition>;) {
>>>       <code that uses continue>
>>>       <increment>
>>>     }
>>>
>>> rather than
>>>
>>>     <initialise>
>>>     while (<condition>) {
>>>       <code that uses continue>
>>>       <increment>
>>>     }
>>>
>>> ?  I don't think I would (and I could make hand-waving arguments about
>>> why I wouldn't) but it's really just a matter to taste.
>>>
>>
>> It can also be a matter of lifetime (for C >= C99), which could
>> potentially impact memory usage.  By using declarations (but not
>> compound literals) in the 'for', such objects needn't've storage for
>> the enclosing block.
>
> That does not match my understanding.  Can you provide supporting
> evidence?
>
> Putting a declaration in a for statement (as opposed to just before a
> while) alters the scope the scope of the name but does not, I think,
> have any effect on the lifetime of the declared object.
>

Sure thing.  C99 6.8.5.3p1 with 6.2.4p6.

Personally, these days I like to declare everything at the top of a 
function, so I don't actually take advantage of this, but it might be 
worth noting, for C >= C99.

- Shao Miller

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

#29299

Shao Miller <sha0.miller@gmail.com> writes:
> On 12/15/2012 17:10, Ben Bacarisse wrote:
>> Shao Miller <sha0.miller@gmail.com> writes:
>>> On 12/15/2012 15:47, Ben Bacarisse wrote:
>>>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
[...]
>>>>> I have used "for" loops where I needed "continue" to restart
>>>>> the loop without incrementing the index.
>>>>>
>>>>> Otherwise, I agree.
>>>>
>>>> So when you want that behaviour you'd write:
>>>>
>>>>     for (<initialise>; <condition>;) {
>>>>       <code that uses continue>
>>>>       <increment>
>>>>     }
>>>>
>>>> rather than
>>>>
>>>>     <initialise>
>>>>     while (<condition>) {
>>>>       <code that uses continue>
>>>>       <increment>
>>>>     }
>>>>
>>>> ?  I don't think I would (and I could make hand-waving arguments about
>>>> why I wouldn't) but it's really just a matter to taste.
>>>>
>>>
>>> It can also be a matter of lifetime (for C >= C99), which could
>>> potentially impact memory usage.  By using declarations (but not
>>> compound literals) in the 'for', such objects needn't've storage for
>>> the enclosing block.
>>
>> That does not match my understanding.  Can you provide supporting
>> evidence?
>>
>> Putting a declaration in a for statement (as opposed to just before a
>> while) alters the scope the scope of the name but does not, I think,
>> have any effect on the lifetime of the declared object.
>>
>
> Sure thing.  C99 6.8.5.3p1 with 6.2.4p6.
>
> Personally, these days I like to declare everything at the top of a 
> function, so I don't actually take advantage of this, but it might be 
> worth noting, for C >= C99.

6.8.5.3p1:
    If *clause-1* is a declaration, the scope of any identifiers
    it declares is the remainder of the declaration and the entire
    loop, including the other two expressions

6.2.4p6:
    For such an object that does not have a variable length array type,
    its lifetime extends from entry into the block with which it is
    associated until execution of that block ends in any way.

So my interpretation of that is:

    void foo(void) { /* lifetime of i starts here */
        this();
        that();
        for (int i = 0 /* scope of i starts here */; i < 100; i ++) {
            the_other_thing(i);
        /* scope of i ends here */
        }
        yet_another_thing();
    /* lifetime of i ends here */
    }

The "block with which it [i] is associated" is the outer block for the
function, not the block that is the statement controlled by the for
loop.

Remember that the statement controlled by a for loop needn't be a block:

    for (int i = 0; i < 100; i ++)
        single_statement();

If `i` were defined just above the for loop, the lifetime and scope would
be the same as they are in my example.

-- 
Keith Thompson (The_Other_Keith) kst-u@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]

#29309

On 12/15/2012 18:43, Keith Thompson wrote:
> Shao Miller <sha0.miller@gmail.com> writes:
>> On 12/15/2012 17:10, Ben Bacarisse wrote:
>>> Shao Miller <sha0.miller@gmail.com> writes:
>>>> On 12/15/2012 15:47, Ben Bacarisse wrote:
>>>>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> [...]
>>>>>> I have used "for" loops where I needed "continue" to restart
>>>>>> the loop without incrementing the index.
>>>>>>
>>>>>> Otherwise, I agree.
>>>>>
>>>>> So when you want that behaviour you'd write:
>>>>>
>>>>>      for (<initialise>; <condition>;) {
>>>>>        <code that uses continue>
>>>>>        <increment>
>>>>>      }
>>>>>
>>>>> rather than
>>>>>
>>>>>      <initialise>
>>>>>      while (<condition>) {
>>>>>        <code that uses continue>
>>>>>        <increment>
>>>>>      }
>>>>>
>>>>> ?  I don't think I would (and I could make hand-waving arguments about
>>>>> why I wouldn't) but it's really just a matter to taste.
>>>>>
>>>>
>>>> It can also be a matter of lifetime (for C >= C99), which could
>>>> potentially impact memory usage.  By using declarations (but not
>>>> compound literals) in the 'for', such objects needn't've storage for
>>>> the enclosing block.
>>>
>>> That does not match my understanding.  Can you provide supporting
>>> evidence?
>>>
>>> Putting a declaration in a for statement (as opposed to just before a
>>> while) alters the scope the scope of the name but does not, I think,
>>> have any effect on the lifetime of the declared object.
>>>
>>
>> Sure thing.  C99 6.8.5.3p1 with 6.2.4p6.
>>
>> Personally, these days I like to declare everything at the top of a
>> function, so I don't actually take advantage of this, but it might be
>> worth noting, for C >= C99.
>
> 6.8.5.3p1:
>      If *clause-1* is a declaration, the scope of any identifiers
>      it declares is the remainder of the declaration and the entire
>      loop, including the other two expressions
>
> 6.2.4p6:
>      For such an object that does not have a variable length array type,
>      its lifetime extends from entry into the block with which it is
>      associated until execution of that block ends in any way.
>

I must _sincerely_ apologize.  This must be a circumstance where 
N1256.PDF differs from C99.  Please forgive me for referring to the 
wrong point!  N1256.PDF's 6.2.4p6:

   "For such an object that does have a variable length array type, its 
lifetime extends from the declaration of the object until execution of 
the program leaves the scope of the declaration.27) If the scope is 
entered recursively, a new instance of the object is created each time. 
The initial value of the object is indeterminate."

> So my interpretation of that is:
>
>      void foo(void) { /* lifetime of i starts here */
>          this();
>          that();
>          for (int i = 0 /* scope of i starts here */; i < 100; i ++) {
>              the_other_thing(i);
>          /* scope of i ends here */
>          }
>          yet_another_thing();
>      /* lifetime of i ends here */
>      }
>
> The "block with which it [i] is associated" is the outer block for the
> function, not the block that is the statement controlled by the for
> loop.
>
> Remember that the statement controlled by a for loop needn't be a block:
>
>      for (int i = 0; i < 100; i ++)
>          single_statement();
>
> If `i` were defined just above the for loop, the lifetime and scope would
> be the same as they are in my example.
>

Because VLAs are the predominant feature for C99 from my perspective, I 
realize now that I've actually skipped mentioning them, but they are 
precisely what I'm referring to.

- Shao Miller

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

#29343

Shao Miller <sha0.miller@gmail.com> writes:
> On 12/15/2012 18:43, Keith Thompson wrote:
>> Shao Miller <sha0.miller@gmail.com> writes:
>>> On 12/15/2012 17:10, Ben Bacarisse wrote:
>>>> Shao Miller <sha0.miller@gmail.com> writes:
[...]
>>>>> It can also be a matter of lifetime (for C >= C99), which could
>>>>> potentially impact memory usage.  By using declarations (but not
>>>>> compound literals) in the 'for', such objects needn't've storage for
>>>>> the enclosing block.
>>>>
>>>> That does not match my understanding.  Can you provide supporting
>>>> evidence?
>>>>
>>>> Putting a declaration in a for statement (as opposed to just before a
>>>> while) alters the scope the scope of the name but does not, I think,
>>>> have any effect on the lifetime of the declared object.
>>>>
>>>
>>> Sure thing.  C99 6.8.5.3p1 with 6.2.4p6.
>>>
>>> Personally, these days I like to declare everything at the top of a
>>> function, so I don't actually take advantage of this, but it might be
>>> worth noting, for C >= C99.
>>
>> 6.8.5.3p1:
>>      If *clause-1* is a declaration, the scope of any identifiers
>>      it declares is the remainder of the declaration and the entire
>>      loop, including the other two expressions
>>
>> 6.2.4p6:
>>      For such an object that does not have a variable length array type,
>>      its lifetime extends from entry into the block with which it is
>>      associated until execution of that block ends in any way.

I was quoting from N1570, the C11 draft; sorry if I didn't make that
clear.  The paragraph numbering of section 6.2.4 changed from C99 to
C11.  N1570 6.2.4p6 is C99 and N1256 6.2.4p5.

Apart from the renumbering, the paragraph discussing non-VLA objects is
word-for-word identical between C99 and N1256; N1570 adds the phrase "or
compound literal".

The following paragraph, discussing VLA objects (which is *not* what I
was discussing) is word-for-word identical in C99, N1256, and N1570.

> I must _sincerely_ apologize.  This must be a circumstance where 
> N1256.PDF differs from C99.  Please forgive me for referring to the 
> wrong point!  N1256.PDF's 6.2.4p6:
>
>    "For such an object that does have a variable length array type, its 
> lifetime extends from the declaration of the object until execution of 
> the program leaves the scope of the declaration.27) If the scope is 
> entered recursively, a new instance of the object is created each time. 
> The initial value of the object is indeterminate."

[...]

> Because VLAs are the predominant feature for C99 from my perspective, I 
> realize now that I've actually skipped mentioning them, but they are 
> precisely what I'm referring to.

Hmm.  I consider VLAs to be just one of a number of features added by
C99, certainly not the predominant one.  Until now, I hadn't even
considered them in the context of this discussion.

Perhaps you could briefly restate the point you were making?

-- 
Keith Thompson (The_Other_Keith) kst-u@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]

#29347

On 12/16/2012 17:21, Keith Thompson wrote:
>
> I was quoting from N1570, the C11 draft; sorry if I didn't make that
> clear.  The paragraph numbering of section 6.2.4 changed from C99 to
> C11.  N1570 6.2.4p6 is C99 and N1256 6.2.4p5.
>

Aha.

> Apart from the renumbering, the paragraph discussing non-VLA objects is
> word-for-word identical between C99 and N1256; N1570 adds the phrase "or
> compound literal".
>

Ah yes, compound literals get a little more consideration, there.

> [...]
>
>
> Hmm.  I consider VLAs to be just one of a number of features added by
> C99, certainly not the predominant one.  Until now, I hadn't even
> considered them in the context of this discussion.
>
> Perhaps you could briefly restate the point you were making?
>

Just that using a 'for' instead of a 'while' when, at first glance, it 
might seem that either would do nicely, have some subtle differences 
regarding memory usage, for VLAs.  Hand-waving the use of 'for' instead 
of 'while' dismisses those subtleties.

The code example I recently offered to Ben B. was:

   #include <stddef.h>
   #define Countof(array) (sizeof (array) / sizeof *(array))

   int finally(size_t * arr) {
       (void) arr;
       return 0;
     }

   int main(void) {
       int n = 42;
       int i = 13;

       for (size_t i = 0, arr[n]; i < Countof(arr) || finally(arr); ++i)
         arr[i] = i;

       int x = i;
       (void) x;

       return 0;
     }

You might notice the suitability of this 'for' for a macro or for 
volatile 'n' (evaluating it only once).  There is no equivalent 'while' 
that I'm aware of where the lifetime (and thus the storage requirement) 
of 'arr' ends after the iteration statement.  I think you'd need to 
surround a 'while' counterpart with a block and some declarations, which 
can have an aesthetic drawback for certain indentation conventions:

   #include <stddef.h>
   #define Countof(array) (sizeof (array) / sizeof *(array))

   int finally(size_t * arr) {
       (void) arr;
       return 0;
     }

   int main(void) {
       int n = 42;
       int i = 13;

       {
           size_t i = 0;
           size_t arr[n];

           while (i < Countof(arr)) {
               arr[i] = i;
               ++i;
             }
           finally(arr);
         }

       int x = i;
       (void) x;

       return 0;
     }

Please also consider a macro:

   #define for_macro(n) \
     for (size_t i = 0, arr[n]; i < Countof(arr) || finally(arr); ++i)

and how you can do:

   for_macro(42)
     statement;

But using 'while' could be trickier to "inject" the 'statement' into the 
enclosing block of the 'while':

   #define while_macro(n, statement) \
     do { \
         size_t i = 0; \
         size_t arr[n]; \
\
         while (i < Countof(arr)) { \
             statement; \
             ++i; \
           } \
         finally(arr); \
       } while (0)

   /* Example usage */
   while_macro(42, arr[i] = i);

and where the statement is itself an iteration, selection, or compound 
statement, it gets uglier.

These are obviously contrived and, as Ben B. mentioned, most likely a 
"useless case."

- Shao Miller

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

#29367

Keith Thompson <kst-u@mib.org> writes:

> Shao Miller <sha0.miller@gmail.com> writes:
>> On 12/15/2012 17:10, Ben Bacarisse wrote:
>>> Shao Miller <sha0.miller@gmail.com> writes:
>>>> On 12/15/2012 15:47, Ben Bacarisse wrote:
>>>>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> [...]
>>>>>> I have used "for" loops where I needed "continue" to restart
>>>>>> the loop without incrementing the index.
>>>>>>
>>>>>> Otherwise, I agree.
>>>>>
>>>>> So when you want that behaviour you'd write:
>>>>>
>>>>>     for (<initialise>; <condition>;) {
>>>>>       <code that uses continue>
>>>>>       <increment>
>>>>>     }
>>>>>
>>>>> rather than
>>>>>
>>>>>     <initialise>
>>>>>     while (<condition>) {
>>>>>       <code that uses continue>
>>>>>       <increment>
>>>>>     }
>>>>>
>>>>> ?  I don't think I would (and I could make hand-waving arguments about
>>>>> why I wouldn't) but it's really just a matter to taste.
>>>>>
>>>>
>>>> It can also be a matter of lifetime (for C >= C99), which could
>>>> potentially impact memory usage.  By using declarations (but not
>>>> compound literals) in the 'for', such objects needn't've storage for
>>>> the enclosing block.
>>>
>>> That does not match my understanding.  Can you provide supporting
>>> evidence?
>>>
>>> Putting a declaration in a for statement (as opposed to just before a
>>> while) alters the scope the scope of the name but does not, I think,
>>> have any effect on the lifetime of the declared object.
>>>
>>
>> Sure thing.  C99 6.8.5.3p1 with 6.2.4p6.
>>
>> Personally, these days I like to declare everything at the top of a 
>> function, so I don't actually take advantage of this, but it might be 
>> worth noting, for C >= C99.
>
> 6.8.5.3p1:
>     If *clause-1* is a declaration, the scope of any identifiers
>     it declares is the remainder of the declaration and the entire
>     loop, including the other two expressions
>
> 6.2.4p6:
>     For such an object that does not have a variable length array type,
>     its lifetime extends from entry into the block with which it is
>     associated until execution of that block ends in any way.
>
> So my interpretation of that is:
>
>     void foo(void) { /* lifetime of i starts here */
>         this();
>         that();
>         for (int i = 0 /* scope of i starts here */; i < 100; i ++) {
>             the_other_thing(i);
>         /* scope of i ends here */
>         }
>         yet_another_thing();
>     /* lifetime of i ends here */
>     }
>
> The "block with which it [i] is associated" is the outer block for the
> function, not the block that is the statement controlled by the for
> loop.

Actually it's the block of the iteration ('for') statement.

> Remember that the statement controlled by a for loop needn't be a block:
>
>     for (int i = 0; i < 100; i ++)
>         single_statement();

The loop body of an iteration statement is always a block, even if
just a single statement (ie, not a compound statement).

> If `i` were defined just above the for loop, the lifetime and scope would
> be the same as they are in my example.

Declaring in the 'for' statement, as opposed to just before, is
more limited in both scope and lifetime.  All of these follow from
6.8.5 p5.

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

#29412

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> 6.8.5.3p1:
>>     If *clause-1* is a declaration, the scope of any identifiers
>>     it declares is the remainder of the declaration and the entire
>>     loop, including the other two expressions
>>
>> 6.2.4p6:
>>     For such an object that does not have a variable length array type,
>>     its lifetime extends from entry into the block with which it is
>>     associated until execution of that block ends in any way.
>>
>> So my interpretation of that is:
>>
>>     void foo(void) { /* lifetime of i starts here */
>>         this();
>>         that();
>>         for (int i = 0 /* scope of i starts here */; i < 100; i ++) {
>>             the_other_thing(i);
>>         /* scope of i ends here */
>>         }
>>         yet_another_thing();
>>     /* lifetime of i ends here */
>>     }
>>
>> The "block with which it [i] is associated" is the outer block for the
>> function, not the block that is the statement controlled by the for
>> loop.
>
> Actually it's the block of the iteration ('for') statement.
>
>> Remember that the statement controlled by a for loop needn't be a block:
>>
>>     for (int i = 0; i < 100; i ++)
>>         single_statement();
>
> The loop body of an iteration statement is always a block, even if
> just a single statement (ie, not a compound statement).

You're right.  I've been assuming that "block" and "compound-statement"
are synonymous, or nearly so, but N1570 6.8.5p5 says:

    An iteration statement is a block whose scope is a strict
    subset of the scope of its enclosing block. The loop body is
    also a block whose scope is a strict subset of the scope of
    the iteration statement.

(It would have been nice if that had been mentioned in the definition
of the word "block" in 6.8p3, but that so-called "definition"
describes how blocks behave, not what they are.)

>> If `i` were defined just above the for loop, the lifetime and scope would
>> be the same as they are in my example.
>
> Declaring in the 'for' statement, as opposed to just before, is
> more limited in both scope and lifetime.  All of these follow from
> 6.8.5 p5.

Yup.

-- 
Keith Thompson (The_Other_Keith) kst-u@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]

#29424

Keith Thompson wrote:
 
> (It would have been nice if that had been mentioned in the definition
> of the word "block" in 6.8p3, but that so-called "definition"
> describes how blocks behave, not what they are.)

I recall some years ago, 
some of us arguing against Douglas A. Gwyn 
about just exactly what a definition was supposed to be.

http://groups.google.com/group/comp.lang.c/msg/d40b6ab86fc45c00

-- 
pete

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

#29398

Keith Thompson wrote:
 
> So my interpretation of that is:
> 
>     void foo(void) { /* lifetime of i starts here */
>         this();
>         that();
>         for (int i = 0 /* scope of i starts here */; i < 100; i ++) {
>             the_other_thing(i);
>         /* scope of i ends here */
>         }
>         yet_another_thing();
>     /* lifetime of i ends here */
>     }
> 
> The "block with which it [i] is associated" is the outer block for the
> function, not the block that is the statement controlled by the for
> loop.

No.
If you're going to say that there is one block 
with which (i) is associated, 
then it is the iteration statement itself, 
which is the block in which (i) is declared.

N1570
6.8.5 Iteration statements
5 An iteration statement is a block ...

In C90 "block" was synonymous with "compound statement".
In C99, that was changed to the way that C11 has it now.

-- 
pete

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

#29413

pete <pfiland@mindspring.com> writes:
> Keith Thompson wrote:
[...]
>> The "block with which it [i] is associated" is the outer block for the
>> function, not the block that is the statement controlled by the for
>> loop.
>
> No.

You're right.

> If you're going to say that there is one block 
> with which (i) is associated, 
> then it is the iteration statement itself, 
> which is the block in which (i) is declared.
>
> N1570
> 6.8.5 Iteration statements
> 5 An iteration statement is a block ...
>
> In C90 "block" was synonymous with "compound statement".
> In C99, that was changed to the way that C11 has it now.

Yes, I missed that.

-- 
Keith Thompson (The_Other_Keith) kst-u@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]

#29306

Shao Miller <sha0.miller@gmail.com> writes:

> On 12/15/2012 17:10, Ben Bacarisse wrote:
>> Shao Miller <sha0.miller@gmail.com> writes:
>>
>>> On 12/15/2012 15:47, Ben Bacarisse wrote:
>>>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>>>
>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>>>
>>>>> (snip)
>>>>>
>>>>>> How odd.  What's the point of have both i and i2?  If either gets
>>>>>> altered in the "some code" part then there is an argument for not
>>>>>> re-writing it as a "for" loop.  Generally, readers will expect the
>>>>>> variables mentioned in a "for" loops to be left alone in the body.  This
>>>>>> is not rule of the language but it's a good rule of thumb.
>>>>>
>>>>> I have used "for" loops where I needed "continue" to restart
>>>>> the loop without incrementing the index.
>>>>>
>>>>> Otherwise, I agree.
>>>>
>>>> So when you want that behaviour you'd write:
>>>>
>>>>     for (<initialise>; <condition>;) {
>>>>       <code that uses continue>
>>>>       <increment>
>>>>     }
>>>>
>>>> rather than
>>>>
>>>>     <initialise>
>>>>     while (<condition>) {
>>>>       <code that uses continue>
>>>>       <increment>
>>>>     }
>>>>
>>>> ?  I don't think I would (and I could make hand-waving arguments about
>>>> why I wouldn't) but it's really just a matter to taste.
>>>>
>>>
>>> It can also be a matter of lifetime (for C >= C99), which could
>>> potentially impact memory usage.  By using declarations (but not
>>> compound literals) in the 'for', such objects needn't've storage for
>>> the enclosing block.
>>
>> That does not match my understanding.  Can you provide supporting
>> evidence?
>>
>> Putting a declaration in a for statement (as opposed to just before a
>> while) alters the scope the scope of the name but does not, I think,
>> have any effect on the lifetime of the declared object.
>
> Sure thing.  C99 6.8.5.3p1 with 6.2.4p6.

These support exactly what I said.  I don't see any support there for
the change in the lifetime that you suggested.

-- 
Ben.

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

#29310

On 12/15/2012 20:24, Ben Bacarisse wrote:
> Shao Miller <sha0.miller@gmail.com> writes:
>
>> On 12/15/2012 17:10, Ben Bacarisse wrote:
>>> Shao Miller <sha0.miller@gmail.com> writes:
>>>
>>>> On 12/15/2012 15:47, Ben Bacarisse wrote:
>>>>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>>>>
>>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>>>>
>>>>>> (snip)
>>>>>>
>>>>>>> How odd.  What's the point of have both i and i2?  If either gets
>>>>>>> altered in the "some code" part then there is an argument for not
>>>>>>> re-writing it as a "for" loop.  Generally, readers will expect the
>>>>>>> variables mentioned in a "for" loops to be left alone in the body.  This
>>>>>>> is not rule of the language but it's a good rule of thumb.
>>>>>>
>>>>>> I have used "for" loops where I needed "continue" to restart
>>>>>> the loop without incrementing the index.
>>>>>>
>>>>>> Otherwise, I agree.
>>>>>
>>>>> So when you want that behaviour you'd write:
>>>>>
>>>>>      for (<initialise>; <condition>;) {
>>>>>        <code that uses continue>
>>>>>        <increment>
>>>>>      }
>>>>>
>>>>> rather than
>>>>>
>>>>>      <initialise>
>>>>>      while (<condition>) {
>>>>>        <code that uses continue>
>>>>>        <increment>
>>>>>      }
>>>>>
>>>>> ?  I don't think I would (and I could make hand-waving arguments about
>>>>> why I wouldn't) but it's really just a matter to taste.
>>>>>
>>>>
>>>> It can also be a matter of lifetime (for C >= C99), which could
>>>> potentially impact memory usage.  By using declarations (but not
>>>> compound literals) in the 'for', such objects needn't've storage for
>>>> the enclosing block.
>>>
>>> That does not match my understanding.  Can you provide supporting
>>> evidence?
>>>
>>> Putting a declaration in a for statement (as opposed to just before a
>>> while) alters the scope the scope of the name but does not, I think,
>>> have any effect on the lifetime of the declared object.
>>
>> Sure thing.  C99 6.8.5.3p1 with 6.2.4p6.
>
> These support exactly what I said.  I don't see any support there for
> the change in the lifetime that you suggested.
>

With _much_ apology, I've assumed that N1256.PDF's 6.2.4p6 is C99's.  I 
am referring to C99's VLAs, which obviously introduce a number of quirks 
(relative to C89/C90).  One of those quirks is that their lifetime and 
scope are fairly closely tied, and it's relevant for a 'for' loop's 
clause-1.  (_Why_ one would declare a VLA in a 'for' loop is a matter of 
practicality, but _that_ one can is a matter of fact.)

Or, I could be missing something.

- Shao Miller

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web