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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#29330

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

> 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.

The "for" and the "while" versions are the same with respect to
lifetime, with or without VLAs.  The loop pattern you commented on had
<initialise> but you decided to make a point about the fact that C99
also permits a declaration there.  That's fine, but your point is still
wrong.  You must then compare

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

with
       <declaration>;
       while (<condition>) {
         <code that uses continue>
         <increment>
       }

which do not differ significantly in the required lifetime of the
declared object.

-- 
Ben.

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

#29337

On 12/16/2012 08:11, Ben Bacarisse wrote:
> Shao Miller <sha0.miller@gmail.com> writes:
>
>> 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.
>
> The "for" and the "while" versions are the same with respect to
> lifetime, with or without VLAs.  The loop pattern you commented on had
> <initialise> but you decided to make a point about the fact that C99
> also permits a declaration there.  That's fine, but your point is still
> wrong.  You must then compare
>
>         for (<declaration>; <condition>;) {
>           <code that uses continue>
>           <increment>
>         }
>
> with
>         <declaration>;
>         while (<condition>) {
>           <code that uses continue>
>           <increment>
>         }
>
> which do not differ significantly in the required lifetime of the
> declared object.
>

How do you "undeclare" the identifier(s) in the 'while' version, after 
the 'while' statement, so as to free up storage?  Do you _need_ to free 
the storage for the identifier(s) in the 'for' version?

It's also a matter of namespace pollution.  Please consider:

   #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;
     }

What value does 'x' land with?  Is the storage for 'arr' required by the 
time 'x' is initialized?  It seems to me that with a 'while', you'd need 
to do some curly brace wrapping.

- Shao Miller

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

#29339

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

> On 12/16/2012 08:11, Ben Bacarisse wrote:
>> Shao Miller <sha0.miller@gmail.com> writes:
>>
>>> 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:
<snip>
>>>>>>>>
>>>>>>>>       for (<initialise>; <condition>;) {
>>>>>>>>         <code that uses continue>
>>>>>>>>         <increment>
>>>>>>>>       }
>>>>>>>>
>>>>>>>> rather than
>>>>>>>>
>>>>>>>>       <initialise>
>>>>>>>>       while (<condition>) {
>>>>>>>>         <code that uses continue>
>>>>>>>>         <increment>
>>>>>>>>       }
<snip>
>>>>>>> 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?
<snip>
>>>>> 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.
>>
>> The "for" and the "while" versions are the same with respect to
>> lifetime, with or without VLAs.  The loop pattern you commented on had
>> <initialise> but you decided to make a point about the fact that C99
>> also permits a declaration there.  That's fine, but your point is still
>> wrong.  You must then compare
>>
>>         for (<declaration>; <condition>;) {
>>           <code that uses continue>
>>           <increment>
>>         }
>>
>> with
>>         <declaration>;
>>         while (<condition>) {
>>           <code that uses continue>
>>           <increment>
>>         }
>>
>> which do not differ significantly in the required lifetime of the
>> declared object.
>
> How do you "undeclare" the identifier(s) in the 'while' version, after
> the 'while' statement, so as to free up storage?  Do you _need_ to
> free the storage for the identifier(s) in the 'for' version?

I don't think these questions help.  I think the difference in opinion
may come from the interpretation of a footnote.  We both agree that the
scope of a for-loop-declared VLA object extends from the declaration to
the end of the controlled statement (that's your first cited
paragraph).  The second citation says:

  For such an object [of automatic storage duration] 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]

Footnote 27 is about what it means to leave the scope:

  [27] Leaving the innermost block containing the declaration, or
       jumping to a point in that block or an embedded block prior to
       the declaration, leaves the scope of the declaration.

Presumably you take falling out of the for loop as "leaving the scope"
but that does not fit the wording of the footnote.

Maybe falling out of the scope *is* "leaving the scope" (i.e. maybe
footnote 27 is there to illustrate a couple of possibilities, rather
than explain the term).  I agree that that's perfectly reasonable, but
there are other cases where going from being in the scope to not being
in it is not the same as leaving it (function calls for example).

On your side, there is evidence that even if footnote 27 is intended to
explain the term, it might simply fail to consider the case of
identifiers declared in for loops.  The evidence being that that occurs
elsewhere.  For example, 6.4.1p4 says:

  If the declarator or type specifier that declares the identifier
  appears inside a block or within the list of parameter declarations in
  a function definition, the identifier has block scope, which
  terminates at the end of the associated block.

Presumably, 6.8.5.3p1 refines this statement, but it would be better if
the above at least mentioned the case of a for loop.

I am leaning you way here.  I suspect the footnote 27 just lists a
couple of possibilities and the natural meaning of "leaving the scope"
applies here, but I am glad it's a debate about a useless case.

<snip>
-- 
Ben.

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

#29366

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

> Shao Miller <sha0.miller@gmail.com> writes:
>
>> 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.
>
> The "for" and the "while" versions are the same with respect to
> lifetime, with or without VLAs.  The loop pattern you commented on had
> <initialise> but you decided to make a point about the fact that C99
> also permits a declaration there.  That's fine, but your point is still
> wrong.  You must then compare
>
>        for (<declaration>; <condition>;) {
>          <code that uses continue>
>          <increment>
>        }
>
> with
>        <declaration>;
>        while (<condition>) {
>          <code that uses continue>
>          <increment>
>        }
>
> which do not differ significantly in the required lifetime of the
> declared object.

I believe they do, because of 6.8.5 p5.

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

#29404

Tim Rentsch <txr@alumni.caltech.edu> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Shao Miller <sha0.miller@gmail.com> writes:
>>
>>> 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.
>>
>> The "for" and the "while" versions are the same with respect to
>> lifetime, with or without VLAs.  The loop pattern you commented on had
>> <initialise> but you decided to make a point about the fact that C99
>> also permits a declaration there.  That's fine, but your point is still
>> wrong.  You must then compare
>>
>>        for (<declaration>; <condition>;) {
>>          <code that uses continue>
>>          <increment>
>>        }
>>
>> with
>>        <declaration>;
>>        while (<condition>) {
>>          <code that uses continue>
>>          <increment>
>>        }
>>
>> which do not differ significantly in the required lifetime of the
>> declared object.
>
> I believe they do, because of 6.8.5 p5.

Ah!  Thank you.  This not only makes things very clear (in particular my
fussing over footnote 27 is irrelevant since it clearly applies when a
for loop exits) it explains what looked to me like inconsistent wording
between 6.2.1 (Scope of identifiers) p4 and 5.8.5.3 (The for statement)
p1.

I think it could be better placed, but at least it's there.

-- 
Ben.

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

#29538

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

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Shao Miller <sha0.miller@gmail.com> writes:
>>>
>>>> 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.
>>>
>>> The "for" and the "while" versions are the same with respect to
>>> lifetime, with or without VLAs.  The loop pattern you commented on had
>>> <initialise> but you decided to make a point about the fact that C99
>>> also permits a declaration there.  That's fine, but your point is still
>>> wrong.  You must then compare
>>>
>>>        for (<declaration>; <condition>;) {
>>>          <code that uses continue>
>>>          <increment>
>>>        }
>>>
>>> with
>>>        <declaration>;
>>>        while (<condition>) {
>>>          <code that uses continue>
>>>          <increment>
>>>        }
>>>
>>> which do not differ significantly in the required lifetime of the
>>> declared object.
>>
>> I believe they do, because of 6.8.5 p5.
>
> Ah!  Thank you.  This not only makes things very clear (in particular my
> fussing over footnote 27 is irrelevant since it clearly applies when a
> for loop exits) it explains what looked to me like inconsistent wording
> between 6.2.1 (Scope of identifiers) p4 and 5.8.5.3 (The for statement)
> p1.
>
> I think it could be better placed, but at least it's there.

Right.  Note that there is similar wording for selection
statements ('if()' and 'switch()').

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

#29293

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

(snip on the comma operator used in for loops, then I wrote)

>> 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>
>  }

It might have started out as a normal "for" loop before I realized 
that the "continue" was needed, but yes. As long as the initialization
was related to the loop, I would probably use for.

I tend to use "while" where the condition is a function call, not
a test on a loop variable, such as with fgets().
 
> ?  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.

-- glen

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

#29278

On Saturday, December 15, 2012 1:47:21 PM UTC, Test wrote:
> I have:
> 
> for (i=0,i2=0;i<10;i++,i2++)
> 
>    {
> 
>    .. some code
> 
>    }
> 
> 
> Is "," (comma) oke here?
>
Yes
> 
> Any caveats? I could not find explanation to comma usage
>
Comma operators are very seldom used because there's not much need for them. 
An exception is in for loops, where you might want to have two loop counters
going at once. Even here, most C programmers prefer the style

for(i=0;i<N;i++)
{
  units[i] = 0;
  tens[i*10] = 0;
}
--
Visit Malcolm's homepage
http://www.malcolmmclean.site11.com/www

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

#29282

Malcolm McLean wrote:
> On Saturday, December 15, 2012 1:47:21 PM UTC, Test wrote:
>> I have:
>>
>> for (i=0,i2=0;i<10;i++,i2++)
>>
>>     {
>>
>>     .. some code
>>
>>     }
>>
>>
>> Is "," (comma) oke here?
>>
> Yes
>>
>> Any caveats? I could not find explanation to comma usage
>>
> Comma operators are very seldom used because there's not much need for them.
> An exception is in for loops, where you might want to have two loop counters
> going at once. Even here, most C programmers prefer the style
>
> for(i=0;i<N;i++)
> {
>    units[i] = 0;
>    tens[i*10] = 0;
> }
> --
> Visit Malcolm's homepage
> http://www.malcolmmclean.site11.com/www
>

I also like:
  for(i=0;i<N;i++)
  {
     const int i2  = (i*10);
     units[i] = 0;
     tens[i2] = 0;
  }

which seems silly for that simple of a loop, but
has come in handy ( especially when i2 is assigned
from a function return )

--
Les Cargill

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

#29279

On 12/15/2012 08:47 AM, Test wrote:
> I have:
> 
> for (i=0,i2=0;i<10;i++,i2++)
>    {
>    .. some code
>    }
> 
> Is "," (comma) oke here?

Yes.

> 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?

The expression i=0 is executed first, though in this particular case it
doesn't matter.

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

The expression E1,E2, where E1 is any expression, and E2 is any
expression other than another comma expression, causes expression E1 to
be evaluated. The result of that evaluation is discarded, so it only
make sense to do this if E1 is an expression with side effects, such as
 a=3, b++, or printf("error:%g", d). After all side effects of E1 are
complete, expression E2 is evaluated. The value of expression E2 is also
the value of the comma expression as a whole. Thus "a = (b++,c)" is
equivalent to "b++; a=c;". It only makes sense to use a comma expression
when such a re-write is not possible, as in a for() statement such as
the one you ask about above.

A key point to understand is that commas are NOT always part of a comma
expression. The parameters of a function declaration and the arguments
of a function call are separated by commas, and the same is true for
function-like macros. Commas separate the initializers for the elements
of an array or members of a structure. A single declaration can declare
multiple declarators, separated by commas, as in "int a,b;". Commas are
used to separate the members of a union or enumeration. Commas are also
used in _Generic() expressions and _Static_assert() declarations, which
are new features of C2011, syntactically similar to function calls.

If you wish to use a comma expression in one of those contexts, you'll
have to parenthesize it, to prevent misinterpretation of the comma.
printf("hello %s", "world!\n") does something different from
printf( ("hello %s", "world!\n") ).
-- 
James Kuyper

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

#29285

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> A key point to understand is that commas are NOT always part of a comma
> expression. The parameters of a function declaration and the arguments
> of a function call are separated by commas, and the same is true for
> function-like macros. Commas separate the initializers for the elements
> of an array or members of a structure. A single declaration can declare
> multiple declarators, separated by commas, as in "int a,b;". Commas are
> used to separate the members of a union or enumeration.

How do commas separate the members of a union?

>                                                         Commas are also
> used in _Generic() expressions and _Static_assert() declarations, which
> are new features of C2011, syntactically similar to function calls.
[...]

-- 
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]

#29292

On 12/15/2012 03:21 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
...
>> ... Commas are
>> used to separate the members of a union or enumeration.
> 
> How do commas separate the members of a union?

They don't - that comment started life as a very different statement
about structs, unions, and enumerations, and I forgot to remove the part
about unions when I did a major re-write of the statement that rendered
it no longer applicable to unions. Sorry for the confusion (I don't
expect that you were confused, but the OP might have been).
-- 
James Kuyper

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

#29315

Keith Thompson wrote:
> 
> James Kuyper <jameskuyper@verizon.net> writes:
> [...]
> > A key point to understand is that commas are NOT always part of a comma
> > expression. The parameters of a function declaration and the arguments
> > of a function call are separated by commas, and the same is true for
> > function-like macros. Commas separate the initializers for the elements
> > of an array or members of a structure. A single declaration can declare
> > multiple declarators, separated by commas, as in "int a,b;". Commas are
> > used to separate the members of a union or enumeration.
> 
> How do commas separate the members of a union?

union u {
    int x, y;
};

:-)

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

#29332

On 12/16/2012 03:09 AM, Philip Lantz wrote:
> Keith Thompson wrote:
>>
>> James Kuyper <jameskuyper@verizon.net> writes:
>> [...]
>>> A key point to understand is that commas are NOT always part of a comma
>>> expression. The parameters of a function declaration and the arguments
>>> of a function call are separated by commas, and the same is true for
>>> function-like macros. Commas separate the initializers for the elements
>>> of an array or members of a structure. A single declaration can declare
>>> multiple declarators, separated by commas, as in "int a,b;". Commas are
>>> used to separate the members of a union or enumeration.
>>
>> How do commas separate the members of a union?
> 
> union u {
>     int x, y;
> };
> 
> :-)

More useful:

union u {
    int x, *y;
};


-- 
James Kuyper

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

#29344

James Kuyper <jameskuyper@verizon.net> writes:
> On 12/16/2012 03:09 AM, Philip Lantz wrote:
>> Keith Thompson wrote:
>>>
>>> James Kuyper <jameskuyper@verizon.net> writes:
>>> [...]
>>>> A key point to understand is that commas are NOT always part of a comma
>>>> expression. The parameters of a function declaration and the arguments
>>>> of a function call are separated by commas, and the same is true for
>>>> function-like macros. Commas separate the initializers for the elements
>>>> of an array or members of a structure. A single declaration can declare
>>>> multiple declarators, separated by commas, as in "int a,b;". Commas are
>>>> used to separate the members of a union or enumeration.
>>>
>>> How do commas separate the members of a union?
>> 
>> union u {
>>     int x, y;
>> };
>> 
>> :-)
>
> More useful:
>
> union u {
>     int x, *y;
> };

Even better:

union u {
    int val, ref[1];
};

I would, of course, seriously berate anyone who did that in production
code.

-- 
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]

#29333

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

Yes.

> 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?

i=0

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

Not being able to find an explanation without looking hard,
might be considered to be a caveat.

Also, as I believe others have mentioned,
if ".. some code" contains a "continue" statement,
then i++ i2++ will be executed at the end of the "for loop"
but not at the end of the "while loop".

-- 
pete

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

#29386

Test <test@.nil.invalid.com> writes:
> 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).


I'm tempted to say that if you don't understand C well enough to answer this 
question yourself, you shouldn't be performing apparently pointless conversions
of one flow control structure to another.

This reinforces something that I've spotted historically - there seems to 
be some strange fetish for using the swiss-army for(;;) where while() is
perfectly suitable.

Phil
-- 
I'm not saying that google groups censors my posts, but there's a strong link
between me saying "google groups sucks" in articles, and them disappearing.

Oh - I guess I might be saying that google groups censors my posts.

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

#29427

Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> This reinforces something that I've spotted historically - there seems to 
> be some strange fetish for using the swiss-army for(;;) where while() is
> perfectly suitable.

Perhaps I should have worded those as just "for" and "while", I wasn't
trying to imply the "(;;)" part, just the iteration statements.

-- 
I'm not saying that google groups censors my posts, but there's a strong link
between me saying "google groups sucks" in articles, and them disappearing.

Oh - I guess I might be saying that google groups censors my posts.

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

#29447

Phil Carmody wrote:
> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> > This reinforces something that I've spotted historically
> > - there seems to be some strange fetish
> > for using the swiss-army for(;;)
> > where while() is perfectly suitable.
> 
> Perhaps I should have worded those as just "for" and "while", I wasn't
> trying to imply the "(;;)" part, just the iteration statements.

for (;;) is special.

while () , doesn't compile, 
even though K&R 3.5 says that they are equivalent.

-- 
pete

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

#29453

pete <pfiland@mindspring.com> writes:

> Phil Carmody wrote:
>> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
>> > This reinforces something that I've spotted historically
>> > - there seems to be some strange fetish
>> > for using the swiss-army for(;;)
>> > where while() is perfectly suitable.
>> 
>> Perhaps I should have worded those as just "for" and "while", I wasn't
>> trying to imply the "(;;)" part, just the iteration statements.
>
> for (;;) is special.
>
> while () , doesn't compile, 
> even though K&R 3.5 says that they are equivalent.

That's a very odd reading of the text!  I've tried a few times and I
can't get that meaning from what's written in my K&R.

-- 
Ben.

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web