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

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

Comma operator in for() statements

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

Contents

  Comma operator in for() statements Geoff <geoff@invalid.invalid> - 2020-03-21 19:51 -0700
    Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-22 03:31 +0000
      Re: Comma operator in for() statements Geoff <geoff@invalid.invalid> - 2020-03-21 23:17 -0700
        Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-22 12:00 +0000
          Re: Comma operator in for() statements Geoff <geoff@invalid.invalid> - 2020-03-22 08:57 -0700
            Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-22 16:20 +0000
              Re: Comma operator in for() statements Geoff <geoff@invalid.invalid> - 2020-03-22 14:02 -0700
                Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-22 21:26 +0000
      Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-22 10:25 +0100
      Re: Comma operator in for() statements Richard Damon <Richard@Damon-Family.org> - 2020-03-22 08:27 -0400
        Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-22 16:31 +0000
    Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-22 00:33 -0400
    Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-22 12:23 +0000
      Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-22 05:47 -0700
        Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-22 14:17 +0000
          Re: Comma operator in for() statements felix@palmen-it.de (Felix Palmen) - 2020-03-22 15:55 +0100
            Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-22 15:01 +0000
              Re: Comma operator in for() statements felix@palmen-it.de (Felix Palmen) - 2020-03-22 16:05 +0100
                Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-22 16:46 +0000
                  Re: Comma operator in for() statements felix@palmen-it.de (Felix Palmen) - 2020-03-22 18:14 +0100
                  Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-22 11:42 -0700
                    Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-22 22:03 +0000
                      Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-22 23:51 -0700
                        Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-23 14:37 +0000
                          Re: Comma operator in for() statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-23 08:41 -0700
                            Re: Comma operator in for() statements Guillaume <message@bottle.org> - 2020-03-23 16:53 +0100
                            Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-23 16:31 +0000
                              Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-23 16:48 +0000
                                Re: Comma operator in for() statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-23 09:53 -0700
                                  Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-23 18:59 +0100
                                    Re: Comma operator in for() statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-23 11:23 -0700
                                      Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-23 19:51 +0000
                                        Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-23 14:28 -0700
                                      Re: Comma operator in for() statements Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-23 13:09 -0700
                                        Re: Comma operator in for() statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-23 13:20 -0700
                                          Re: Comma operator in for() statements scott@slp53.sl.home (Scott Lurndal) - 2020-03-23 20:26 +0000
                                          Re: Comma operator in for() statements Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-23 13:55 -0700
                                            Re: Comma operator in for() statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-23 15:43 -0700
                                              Re: Comma operator in for() statements Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-23 16:27 -0700
                                                Re: Comma operator in for() statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-23 17:13 -0700
                                                  Re: Comma operator in for() statements Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-23 21:11 -0700
                                                Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-24 00:19 +0000
                                                Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-24 10:30 +0100
                                                  Re: Comma operator in for() statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-24 03:07 -0700
                                                    Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-24 11:37 +0100
                                                  Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-24 11:18 +0000
                                                    Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-24 13:23 +0100
                                                      Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-24 14:53 +0000
                                                        Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-25 10:35 +0100
                                                          Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-25 11:12 +0000
                                                      Re: Comma operator in for() statements Ike Naar <ike@sdf.lonestar.org> - 2020-03-26 19:21 +0000
                                                    Re: Comma operator in for() statements luser droog <luser.droog@gmail.com> - 2020-03-24 21:22 -0700
                                                      Re: Comma operator in for() statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-03-27 06:46 -0700
                                                        Re: Comma operator in for() statements luser droog <luser.droog@gmail.com> - 2020-03-28 01:01 -0700
                                                          Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-28 11:26 +0000
                                                            Re: Comma operator in for() statements luser droog <luser.droog@gmail.com> - 2020-03-28 14:22 -0700
                                                              Re: Comma operator in for() statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 08:12 -0700
                                                                Re: Comma operator in for() statements luser droog <luser.droog@gmail.com> - 2020-04-02 12:21 -0700
                                                                  Re: Comma operator in for() statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 19:43 -0700
                                                  Re: Comma operator in for() statements Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-24 12:56 -0700
                                                  Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-24 23:44 +0000
                                              Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-23 17:10 -0700
                                          Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-24 10:17 +0100
                                  Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-23 18:13 +0000
                          Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-23 09:32 -0700
                            Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-23 19:06 +0100
                          Re: Comma operator in for() statements Richard Damon <Richard@Damon-Family.org> - 2020-03-23 13:23 -0400
                            Re: Comma operator in for() statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-23 10:33 -0700
                              Re: Comma operator in for() statements Guillaume <message@bottle.org> - 2020-03-23 18:34 +0100
                              Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-23 18:18 +0000
                          Re: Comma operator in for() statements Ike Naar <ike@sdf.lonestar.org> - 2020-03-23 22:29 +0000
                            Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-23 23:13 +0000
              Re: Comma operator in for() statements richard@cogsci.ed.ac.uk (Richard Tobin) - 2020-03-22 15:17 +0000
            Re: Comma operator in for() statements nobody@example.org (Scott) - 2020-03-22 16:16 +0000
              Re: Comma operator in for() statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-23 07:22 -0700
              Re: Comma operator in for() statements Guillaume <message@bottle.org> - 2020-03-25 15:10 +0100
                Re: Comma operator in for() statements Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-25 15:18 +0000
            Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-22 16:27 +0000
            Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-22 15:07 -0400
          Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-22 11:33 -0700
        Re: Comma operator in for() statements Anton Shepelev <anton.txt@g{oogle}mail.com> - 2020-03-24 20:25 +0300
          Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-24 23:25 +0000
            Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-25 01:55 +0000
              Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-25 11:01 +0000
            Re: Comma operator in for() statements Anton Shepelev <anton.txt@g{oogle}mail.com> - 2020-03-25 14:59 +0300
              Re: Comma operator in for() statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-03-27 07:42 -0700
                Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-27 14:51 +0000
                  Re: Comma operator in for() statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 19:20 -0700
          Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-24 20:01 -0400
            Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-25 02:05 +0000
              Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-25 15:13 +0000
            Re: Comma operator in for() statements Anton Shepelev <anton.txt@g{oogle}mail.com> - 2020-03-25 15:05 +0300
              Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-25 10:04 -0400
      Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-22 14:49 +0100
    Re: Comma operator in for() statements Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-03-22 09:24 -0600
      Re: Comma operator in for() statements Geoff <geoff@invalid.invalid> - 2020-03-22 14:51 -0700
        Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-22 20:13 -0400
          Re: Comma operator in for() statements Geoff <geoff@invalid.invalid> - 2020-03-23 12:16 -0700
            Re: Comma operator in for() statements Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-23 13:16 -0700
            Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-23 17:16 -0400
              Re: Comma operator in for() statements scott@slp53.sl.home (Scott Lurndal) - 2020-03-23 22:40 +0000
    Re: Comma operator in for() statements Guillaume <message@bottle.org> - 2020-03-22 17:31 +0100
      Re: Comma operator in for() statements Geoff <geoff@invalid.invalid> - 2020-03-22 12:28 -0700
        Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-22 15:35 -0400
          Re: Comma operator in for() statements Geoff <geoff@invalid.invalid> - 2020-03-22 13:43 -0700
    Re: Comma operator in for() statements Les Cargill <lcargill99@comcast.com> - 2020-03-22 13:50 -0500
      Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-22 19:25 +0000
        Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-22 21:52 +0100
          Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-22 21:15 +0000
            Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-23 09:17 +0100
    Re: Comma operator in for() statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-03-27 08:02 -0700

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

#150807

James Kuyper to Bart:

> > Most C coders here would still see that as for-loop.
> >
> > I see it as just a while loop:
> >
> >      count = 0;
> >      ent = master;
> >
> >      while (ent) {
> >          ++count;
> >          ent = ent->chain;
> >      }
> >
> All C coders see it as a for-loop. You have very strong
> preferences for a language significantly different than C,
> and let those preferences interfere with your ability to
> understand what C actually is. As a result, you're not
> really a C coder, just someone who writes C code without
> properly understanding it.

I see it as a while-loop, too, so count me with Bart.  My
negative criticism of C's `for' statement is that it is
essentialy a rather complicated *functional* statement,
because it comprises four pieces of code that are executed
in a non-trivial order and with non-trivial relations.
Passing pieces of code to statements is functional
programming.  In procedural programming, one passes data,
that is, in our case, -- index boundaries.

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

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

#150814

Anton Shepelev <anton.txt@g{oogle}mail.com> writes:

> James Kuyper to Bart:
>
>> > Most C coders here would still see that as for-loop.
>> >
>> > I see it as just a while loop:
>> >
>> >      count = 0;
>> >      ent = master;
>> >
>> >      while (ent) {
>> >          ++count;
>> >          ent = ent->chain;
>> >      }
>> >
>> All C coders see it as a for-loop. You have very strong
>> preferences for a language significantly different than C,
>> and let those preferences interfere with your ability to
>> understand what C actually is. As a result, you're not
>> really a C coder, just someone who writes C code without
>> properly understanding it.
>
> I see it as a while-loop, too, so count me with Bart.  My
> negative criticism of C's `for' statement is that it is
> essentialy a rather complicated *functional* statement,
> because it comprises four pieces of code that are executed
> in a non-trivial order and with non-trivial relations.
> Passing pieces of code to statements is functional
> programming.  In procedural programming, one passes data,
> that is, in our case, -- index boundaries.

What about the body?  What about the condition in an 'if' and the arms
of an 'if'.  The condition and body of a while?  These are all
constructs that 'take' (in the broad sense you seem to be using the
word) code not data.  I don't see how this view singles out C's 'for'
loop.

-- 
Ben.

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

#150818

On 24/03/2020 23:25, Ben Bacarisse wrote:
> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:

>> I see it as a while-loop, too, so count me with Bart.  My
>> negative criticism of C's `for' statement is that it is
>> essentialy a rather complicated *functional* statement,
>> because it comprises four pieces of code that are executed
>> in a non-trivial order and with non-trivial relations.
>> Passing pieces of code to statements is functional
>> programming.  In procedural programming, one passes data,
>> that is, in our case, -- index boundaries.
> 
> What about the body?  What about the condition in an 'if' and the arms
> of an 'if'.  The condition and body of a while?  These are all
> constructs that 'take' (in the broad sense you seem to be using the
> word) code not data.  I don't see how this view singles out C's 'for'
> loop.

Those are executed or skipped over in order as you pass through them in 
the source. Of a loop such as this:

   for (A; B; C) D;

At least one part, C, has deferred execution. Execution order is A; B; 
D; C; ... B; C; D; B;

Part A is executed once, then the loop [re-]iterates in the middle of 
the for-header (B), skips C, executes D /then/ C... It's a little messy.

If you take a more generic for-loop, such as:

    for I in A

which are usually concerned with I iterating in some fashion over the 
bounds or values of A, then there are no actual elements that you 
extract and say these are executed here, and those are executed there.

The mechanisms necessary for initialising and iterating are taken care 
of behind the scenes; what I and A provide are data parameters, not code.

BTW C seems to allows this:

     for (int i; i<10; ++i) {printf("%d\n",i);}

i is not initialised, so one of the many problems with this type of 
loop. Whether a compiler says anything depends on which compiler, and 
which options.

But try to imagine any compiler of:

    for i in 0..9

not initialising i properly. It just can't happen.

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

#150822

Bart <bc@freeuk.com> writes:

> On 24/03/2020 23:25, Ben Bacarisse wrote:
>> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
>
>>> I see it as a while-loop, too, so count me with Bart.  My
>>> negative criticism of C's `for' statement is that it is
>>> essentialy a rather complicated *functional* statement,
>>> because it comprises four pieces of code that are executed
>>> in a non-trivial order and with non-trivial relations.
>>> Passing pieces of code to statements is functional
>>> programming.  In procedural programming, one passes data,
>>> that is, in our case, -- index boundaries.
>>
>> What about the body?  What about the condition in an 'if' and the arms
>> of an 'if'.  The condition and body of a while?  These are all
>> constructs that 'take' (in the broad sense you seem to be using the
>> word) code not data.  I don't see how this view singles out C's 'for'
>> loop.
>
> Those are executed or skipped over in order as you pass through them
> in the source. Of a loop such as this:
>
>   for (A; B; C) D;
>
> At least one part, C, has deferred execution. Execution order is A; B;
> D; C; ... B; C; D; B;

I can't relate what you are saying to my comment.  AS seemed to be
saying that C's for is not "procedural" because it's like a function
parameterised with code.  My point was that that is true of all control
syntax.

-- 
Ben.

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

#150824

Ben Bacarisse to Anton Shepelev:

> > My negative criticism of C's `for' statement is that it
> > is essentialy a rather complicated *functional*
> > statement, because it comprises four pieces of code that
> > are executed in a non-trivial order and with non-trivial
> > relations.  Passing pieces of code to statements is
> > functional programming.  In procedural programming, one
> > passes data, that is, in our case, -- index boundaries.
>
> What about the body?

Indeed.  I was wrong, and should have named three instead of
four functional pieces of code.

> What about the condition in an 'if' and the arms of an
> 'if'.

The codition of an `if' is not a piece of code passed to a
statement because it is executed only once, and can be
replaced by its pre-calculated truth value, taking into
account short-circuit evaluation and C's vague separation
between statements and expressions.

The body (or bodies) of control statmenets are not, in my
view, passed to statements at all.  Rather, the control-flow
statements are mark-up around blocks of linear (non-control)
code.  Operator braces {} are just mark up.

> The condition and body of a while?

Yes, `while' "takes" the loop invariant in the same sense as
does `for', yet `while' is much simpler and much more
intutive in that it "takes" only one piece of code, which
can be kept strictly as control code (only checks, no
assignments), and that it is executed in the intuitive order
of appearance.  The same applies to do..while.

One of the worst abuses of `while' is code for which many
programmers praise C:

  char *s, *d;
  /* ... */
  while (*d++ = *s++);

It employs several means of obfuscation:

  1.  loop-control statements with side effects,

  2.  use of counter-intuitive post-increment operator on
      both parts of an assibnment.

  3.  confusion of logical condition and comparison with
      zero.

  4.  an empty body of the `while' statement.

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

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

#150859

Anton Shepelev <anton.txt@g{oogle}mail.com> writes:

> Ben Bacarisse to Anton Shepelev:
>
>>> My negative criticism of C's `for' statement is that it
>>> is essentialy a rather complicated *functional*
>>> statement, because it comprises four pieces of code that
>>> are executed in a non-trivial order and with non-trivial
>>> relations.  Passing pieces of code to statements is
>>> functional programming.  In procedural programming, one
>>> passes data, that is, in our case, -- index boundaries.
>>
>> What about the body?
>
> Indeed.  I was wrong, and should have named three instead of
> four functional pieces of code.
>
>> What about the condition in an 'if' and the arms of an
>> 'if'.
>
> The codition of an `if' is not a piece of code passed to a
> statement because it is executed only once, and can be
> replaced by its pre-calculated truth value, taking into
> account short-circuit evaluation and C's vague separation
> between statements and expressions.
>
> The body (or bodies) of control statmenets are not, in my
> view, passed to statements at all.  Rather, the control-flow
> statements are mark-up around blocks of linear (non-control)
> code.  Operator braces {} are just mark up.
>
>> The condition and body of a while?
>
> Yes, `while' "takes" the loop invariant in the same sense as
> does `for', yet `while' is much simpler and much more
> intutive in that it "takes" only one piece of code, which
> can be kept strictly as control code (only checks, no
> assignments), and that it is executed in the intuitive order
> of appearance.  The same applies to do..while.
>
> One of the worst abuses of `while' is code for which many
> programmers praise C:
>
>   char *s, *d;
>   /* ... */
>   while (*d++ = *s++);
>
> It employs several means of obfuscation:
>
>   1.  loop-control statements with side effects,
>
>   2.  use of counter-intuitive post-increment operator on
>       both parts of an assibnment.
>
>   3.  confusion of logical condition and comparison with
>       zero.
>
>   4.  an empty body of the `while' statement.

It's idiomatic C.  Perhaps more importantly, C not only allows
such constructions but embraces them stylistically.  Such things
have been part of C since its earliest beginnings.  If someone
wants to write Pascal-style code they should write in Pascal.

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

#150860

On 27/03/2020 14:42, Tim Rentsch wrote:
> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:

>> One of the worst abuses of `while' is code for which many
>> programmers praise C:
>>
>>    char *s, *d;
>>    /* ... */
>>    while (*d++ = *s++);
>>
>> It employs several means of obfuscation:
>>
>>    1.  loop-control statements with side effects,
>>
>>    2.  use of counter-intuitive post-increment operator on
>>        both parts of an assibnment.
>>
>>    3.  confusion of logical condition and comparison with
>>        zero.
>>
>>    4.  an empty body of the `while' statement.
> 
> It's idiomatic C.  Perhaps more importantly, C not only allows
> such constructions but embraces them stylistically.  Such things
> have been part of C since its earliest beginnings.  If someone
> wants to write Pascal-style code they should write in Pascal.
> 


What happened to writing code in the clearest manner and leaving it to 
the compiler to optimise?

Then you should be able to use any idiom.

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

#150968

Bart <bc@freeuk.com> writes:

> On 27/03/2020 14:42, Tim Rentsch wrote:
>
>> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
>>
>>> One of the worst abuses of `while' is code for which many
>>> programmers praise C:
>>>
>>>    char *s, *d;
>>>    /* ... */
>>>    while (*d++ = *s++);
>>>
>>> It employs several means of obfuscation:
>>>
>>>    1.  loop-control statements with side effects,
>>>
>>>    2.  use of counter-intuitive post-increment operator on
>>>        both parts of an assibnment.
>>>
>>>    3.  confusion of logical condition and comparison with
>>>        zero.
>>>
>>>    4.  an empty body of the `while' statement.
>>
>> It's idiomatic C.  Perhaps more importantly, C not only allows
>> such constructions but embraces them stylistically.  Such things
>> have been part of C since its earliest beginnings.  If someone
>> wants to write Pascal-style code they should write in Pascal.
>
> What happened to writing code in the clearest manner and leaving it
> to the compiler to optimise?

Sure, but where do you draw the line?

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

#150817

On 3/24/20 1:25 PM, Anton Shepelev wrote:
> James Kuyper to Bart:
> 
>>> Most C coders here would still see that as for-loop.
>>>
>>> I see it as just a while loop:
>>>
>>>      count = 0;
>>>      ent = master;
>>>
>>>      while (ent) {
>>>          ++count;
>>>          ent = ent->chain;
>>>      }
>>>
>> All C coders see it as a for-loop. You have very strong
>> preferences for a language significantly different than C,
>> and let those preferences interfere with your ability to
>> understand what C actually is. As a result, you're not
>> really a C coder, just someone who writes C code without
>> properly understanding it.
> 
> I see it as a while-loop, too, so count me with Bart.  My

Seeing it as a while statement requires ignoring the C syntax: while
statements start with the "while" keyword. Statements that start with
the "for" keyword are for statements, not while statements. I'm pointing
out the obvious, not because I think you don't know the difference, but
because I think it's stupid to using working that implies that it isn't
a difference.

Seeing it as equivalent to a compound statement that includes the
initializer followed by a while statement is quite reasonable - with the
exception of the way the continue statement is handled, the two are
quite similar. C90 actually described the for-statement that way (except
for the compound-statement part, which wasn't needed in C90).
Starting with C99, the for loop's description is independent of the
while statement's description, but the meaning is essentially unchanged,
other than the fact that it is now permissible to declare identifiers in
the first section of a for statement.

However, expressing that equivalence by saying that a for-statement IS a
while-statement is just plain stupid. Among other things, it ignores the
initializer.

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

#150819

On 25/03/2020 00:01, James Kuyper wrote:
> On 3/24/20 1:25 PM, Anton Shepelev wrote:
>> James Kuyper to Bart:
>>
>>>> Most C coders here would still see that as for-loop.
>>>>
>>>> I see it as just a while loop:
>>>>
>>>>       count = 0;
>>>>       ent = master;
>>>>
>>>>       while (ent) {
>>>>           ++count;
>>>>           ent = ent->chain;
>>>>       }
>>>>
>>> All C coders see it as a for-loop. You have very strong
>>> preferences for a language significantly different than C,
>>> and let those preferences interfere with your ability to
>>> understand what C actually is. As a result, you're not
>>> really a C coder, just someone who writes C code without
>>> properly understanding it.
>>
>> I see it as a while-loop, too, so count me with Bart.  My
> 
> Seeing it as a while statement requires ignoring the C syntax: while
> statements start with the "while" keyword. Statements that start with
> the "for" keyword are for statements, not while statements. I'm pointing
> out the obvious, not because I think you don't know the difference, but
> because I think it's stupid to using working that implies that it isn't
> a difference.
> 
> Seeing it as equivalent to a compound statement that includes the
> initializer followed by a while statement is quite reasonable - with the
> exception of the way the continue statement is handled, the two are
> quite similar. C90 actually described the for-statement that way (except
> for the compound-statement part, which wasn't needed in C90).
> Starting with C99, the for loop's description is independent of the
> while statement's description, but the meaning is essentially unchanged,
> other than the fact that it is now permissible to declare identifiers in
> the first section of a for statement.
> 
> However, expressing that equivalence by saying that a for-statement IS a
> while-statement is just plain stupid. Among other things, it ignores the
> initializer.
> 
It is the task that is being done that is seen as a while-loop. Although 
that task is not easy to identify in for-loop form.

I think I would be less critical of C's for-loop if it was instead 
written like this:

    while (int i=0; i<N; ++i) {...}

With 2 of the expressions optional leaving only the middle one for a 
regular while-loop.

Then 'for' can be reserved for ordinary iteration with an official index 
variable.

It would mean I could instantly identify these main classes of loop:

   while (B) ...         Regular while loop

   for (i, A, B) ....    Will always be iteration (may need to be A..B-1
                         for C language)

   while (A; B; C) ...   Warning bells sound ...

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

#150834

On 25/03/2020 02:05, Bart wrote:

> I think I would be less critical of C's for-loop if it was instead 
> written like this:
> 
>     while (int i=0; i<N; ++i) {...}
> 
> With 2 of the expressions optional leaving only the middle one for a 
> regular while-loop.
> 
> Then 'for' can be reserved for ordinary iteration with an official index 
> variable.
> 
> It would mean I could instantly identify these main classes of loop:
> 
>    while (B) ...         Regular while loop
> 
>    for (i, A, B) ....    Will always be iteration (may need to be A..B-1
>                          for C language)
> 
>    while (A; B; C) ...   Warning bells sound ...


Since traversing a linked list is a common example put forward for a 
non-iterative for-loop, I've tried to come with a dedicated language 
features that. (Not for C, and not implemented anyway yet).

Syntax and keywords, and whether it will a variation of an existing loop 
type, or a new one to avoid vonfusion, is to be decided. Tentative 
syntax might be:

    for A in B by C do ... end

A is the loop variable, and here it would need to be a pointer of type 
T*. It can be auto-declared.

B is the head of the linked list to start from, also of type T*.

C is the name of a struct field that is used to access the next node in 
the list. (Unlike iteration where ++ or -- can be assumed, this must be 
specified.)

A and C are pieces of information that are provided, rather than actual 
statements or expressions to be evaluated. B is evaluated once.

It works like to this (in C syntax this time and applying also a C 
block-scope):

{   T* A = B;
     while (A) {
         ...
         A = A->C;
     }
}

(In my version, if ever implemented, A will be readonly ('const') while 
allowing those two implicit assignments. The loop will have an optional 
'else' part for normal exit, and as well as extra loop controls over 
that C provides, such as 'restart'.)

Applied to the example in the OP, it would look like this:

     int count := 0
     for ent in master by chain do ++count end

In my language, loop statements nominally return values, but these are 
usually 'void'. An interesting variation would be, if the return value 
/was/ used, then that could be the number of iterations executed. Then 
the OP's example would look like this:

     int count := for ent in master by chain do end

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

#150825

James Kuyper to Anton Shepelev:

> > I see it as a while-loop, too, so count me with Bart.
> > My
>
> Seeing it as a while statement requires ignoring the C
> syntax: while statements start with the "while" keyword.
> Statements that start with the "for" keyword are for
> statements, not while statements. [...]

I am sorry for the misunderstaing, James.  What I meant is
that I see the algorithm implemented in that `for' loop as
a natural subject of a `while' loop, because we traverse a
list while the current element is not the last.

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

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

#150832

On 3/25/20 8:05 AM, Anton Shepelev wrote:
> James Kuyper to Anton Shepelev:
> 
>>> I see it as a while-loop, too, so count me with Bart.
>>> My
>>
>> Seeing it as a while statement requires ignoring the C
>> syntax: while statements start with the "while" keyword.
>> Statements that start with the "for" keyword are for
>> statements, not while statements. [...]
> 
> I am sorry for the misunderstaing, James.  What I meant is
> that I see the algorithm implemented in that `for' loop as
> a natural subject of a `while' loop, because we traverse a
> list while the current element is not the last.

Well, that doesn't single out the while() loop. The truth of that
assertion can be derived from what the standard says about all four
types of iteration statements:

"An iteration statement causes a statement called the loop body to be
executed repeatedly until the controlling expression compares equal to
0. The repetition occurs regardless of whether the loop body is entered
from the iteration statement or by a jump." (6.8.5p4).

You could, with equal justification, say that the algorithm implemented
by a while loop is the natural subject for a for loop. I could easily
imagine an implementation where for loops are treated as fundamental, and

    while( expression ) statement

is translated as

   for(; expression;) statement

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

#150721

On 22/03/2020 13:23, Bart wrote:
> On 22/03/2020 02:51, Geoff wrote:
>> I'm aware of the hazards of using the comma operator in the tested
>> expression but I ran across this example and I think it should be
>> refactored, but how?
>>
>>     for (count = 0, ent = master; ent; ent = ent->chain, count++)
>>                 ;
>>
>>
>> My first instinct is to write it:
>>
>>         for (count = 0; ent; count++)
>>         {
>>             ent = master;
>>             ent = ent->chain;
>>         }
>>
>> But is this correct?
>>
> 
> Most C coders here would still see that as for-loop.

It /is/ a for-loop.  It's got a "for" in it.  It might not be a Bart-for 
loop, just as it is not a BASIC-for loop.  And many C coders (myself 
included) might not think that this particular for-loop is the best 
structure for the task in hand, but that's another issue.

Please remember that in a C newsgroup, a "for-loop" means a /C/ 
for-loop.  Not a BASIC for-loop, or a FORTRAN for-loop, or a BOL for-loop.

> 
> I see it as just a while loop:
> 
>      count = 0;
>      ent = master;
> 
>      while (ent) {
>          ++count;
>          ent = ent->chain;
>      }
> 

What you mean is you think a while-loop would be a better way to express 
the intent of the code.  That is certainly an option.  I would not have 
any objection to that code, other than that I would expect "count" and 
"ent" to be defined and initialised here.

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

#150727

Geoff <geoff@invalid.invalid> writes:

> I'm aware of the hazards of using the comma operator in the tested
> expression but I ran across this example and I think it should be
> refactored, but how?
>
> 	for (count = 0, ent = master; ent; ent = ent->chain, count++)
> 				;
>
>
> My first instinct is to write it:
>
> 		for (count = 0; ent; count++)
> 		{
> 			ent = master;
> 			ent = ent->chain;
> 		}
>
> But is this correct?

No -- you're reinitializing ent on each iteration.  Your refactor,
corrected, would be

ent = master;
for (count = 0; ent; count++)
{
    ent = ent->chain;
}

This is in a sense backwards from how I would do it:

count = 0;
for (ent = master; ent; ent = ent->chain)
{
    count++;
}

You want the iterator in your loop control to be the same variable
you're checking for termination.

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

#150752

On Sun, 22 Mar 2020 09:24:19 -0600, Joe Pfeiffer
<pfeiffer@cs.nmsu.edu> wrote:

>Geoff <geoff@invalid.invalid> writes:
>
>> I'm aware of the hazards of using the comma operator in the tested
>> expression but I ran across this example and I think it should be
>> refactored, but how?
>>
>> 	for (count = 0, ent = master; ent; ent = ent->chain, count++)
>> 				;
>>
>>
>> My first instinct is to write it:
>>
>> 		for (count = 0; ent; count++)
>> 		{
>> 			ent = master;
>> 			ent = ent->chain;
>> 		}
>>
>> But is this correct?
>
>No -- you're reinitializing ent on each iteration.  Your refactor,
>corrected, would be
>
>ent = master;
>for (count = 0; ent; count++)
>{
>    ent = ent->chain;
>}
>
>This is in a sense backwards from how I would do it:
>
>count = 0;
>for (ent = master; ent; ent = ent->chain)
>{
>    count++;
>}
>
>You want the iterator in your loop control to be the same variable
>you're checking for termination.

Your answer is consistent with Ben Bacarisse's answer. It's the
solution I chose to implement and it has been tested to work.

In retrospect my instinct was wrong and the effect of the comma
operators is such that my refactor was the opposite of the desired
effects of the original author. Left of the first comma is the
initializer of count, right of it is initializer of ent, followed by
chaining of ent and the count increment. 

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

#150754

On 3/22/20 5:51 PM, Geoff wrote:
> On Sun, 22 Mar 2020 09:24:19 -0600, Joe Pfeiffer
> <pfeiffer@cs.nmsu.edu> wrote:
> 
>> Geoff <geoff@invalid.invalid> writes:
>>
>>> I'm aware of the hazards of using the comma operator in the tested
>>> expression but I ran across this example and I think it should be
>>> refactored, but how?
>>>
>>> 	for (count = 0, ent = master; ent; ent = ent->chain, count++)
...
> In retrospect my instinct was wrong and the effect of the comma
> operators is such that my refactor was the opposite of the desired
> effects of the original author. Left of the first comma is the
> initializer of count, right of it is initializer of ent, followed by
> chaining of ent and the count increment. 

You still seem to be under that there is some significant issue here
involving the comma operator. Do you understand that it would have had
exactly the same behavior if it had been written:

    for (ent = master, count = 0; ent; ent = count++, ent->chain)
        ;

?
If any of those variables had been declared 'volatile' or in
multi-threaded code, that re-write could in principle make a difference
- but it shouldn't matter in any ordinary context.

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

#150774

On Sun, 22 Mar 2020 20:13:17 -0400, James Kuyper
<jameskuyper@alumni.caltech.edu> wrote:

>On 3/22/20 5:51 PM, Geoff wrote:
>> On Sun, 22 Mar 2020 09:24:19 -0600, Joe Pfeiffer
>> <pfeiffer@cs.nmsu.edu> wrote:
>> 
>>> Geoff <geoff@invalid.invalid> writes:
>>>
>>>> I'm aware of the hazards of using the comma operator in the tested
>>>> expression but I ran across this example and I think it should be
>>>> refactored, but how?
>>>>
>>>> 	for (count = 0, ent = master; ent; ent = ent->chain, count++)
>...
>> In retrospect my instinct was wrong and the effect of the comma
>> operators is such that my refactor was the opposite of the desired
>> effects of the original author. Left of the first comma is the
>> initializer of count, right of it is initializer of ent, followed by
>> chaining of ent and the count increment. 
>
>You still seem to be under that there is some significant issue here
>involving the comma operator. Do you understand that it would have had
>exactly the same behavior if it had been written:
>
>    for (ent = master, count = 0; ent; ent = count++, ent->chain)
>        ;
>
>?
>If any of those variables had been declared 'volatile' or in
>multi-threaded code, that re-write could in principle make a difference
>- but it shouldn't matter in any ordinary context.

James,
Your rewrite of the line is worse than mine. ent is of type edict_t*
and you have assigned an int value to it. Logically incorrect and not
equivalent to the original code.

I have already accepted your explanation as to where I went wrong in
my original rewrite and I have accepted Ben's recommendations and the
refactored code has been tested in the application and it works
exactly as it should. No further discussion is needed.

As for the comma operator, what does the standard have to say about
how the comma operator works in this context? Or in ANY context for
that matter?

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

#150777

Geoff <geoff@invalid.invalid> writes:
[...]
> As for the comma operator, what does the standard have to say about
> how the comma operator works in this context? Or in ANY context for
> that matter?

The standard says nothing about how the comma operator works in the
context of a for loop, because there's nothing special to say about
that context.  What it says about the comma operator in general is:

    The left operand of a comma operator is evaluated as a void
    expression; there is a sequence point between its evaluation and
    that of the right operand. Then the right operand is evaluated;
    the result has its type and value.

That's from N1570 6.5.17.  N1570 is the most recent public draft of the
C11 standard.  You can get a copy from

    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#150781

On 3/23/20 3:16 PM, Geoff wrote:
> On Sun, 22 Mar 2020 20:13:17 -0400, James Kuyper
> <jameskuyper@alumni.caltech.edu> wrote:
> 
>> On 3/22/20 5:51 PM, Geoff wrote:
...
>>> In retrospect my instinct was wrong and the effect of the comma
>>> operators is such that my refactor was the opposite of the desired
>>> effects of the original author. Left of the first comma is the
>>> initializer of count, right of it is initializer of ent, followed by
>>> chaining of ent and the count increment. 
>>
>> You still seem to be under that there is some significant issue here
>> involving the comma operator. Do you understand that it would have had
>> exactly the same behavior if it had been written:
>>
>>    for (ent = master, count = 0; ent; ent = count++, ent->chain)
>>        ;
>>
>> ?
>> If any of those variables had been declared 'volatile' or in
>> multi-threaded code, that re-write could in principle make a difference
>> - but it shouldn't matter in any ordinary context.
> 
> James,
> Your rewrite of the line is worse than mine. ent is of type edict_t*
> and you have assigned an int value to it. Logically incorrect and not
> equivalent to the original code.

That was a typo. Sorry! It was supposed to be

    for (ent = master, count = 0; ent; count++, ent = ent->chain)
       ;

> I have already accepted your explanation as to where I went wrong in
> my original rewrite and I have accepted Ben's recommendations and the
> refactored code has been tested in the application and it works
> exactly as it should. No further discussion is needed.

I would have thought so, but you wrote your latest comment about the
comma operator just yesterday at 20:13 in zone -4, after you had already
accepted my explanation and Ben's recommendations and tested the code to
ensure that it works. The comment you made after all those things had
occurred (which is quoted above) is worded in a way that makes it seem
likely that you're still confused about something that involves the
comma operator - but I haven't been able to identify what it is you're
confused about.

I can explain what it is that gives me that impression: you seemed to
attach some importance to the fact that "ent = master" is to the left of
"count = 0", and similarly that "ent = ent->chain" is to the left of
"count++". For each of those pairs of expressions, the one on the left
is guaranteed to be evaluated, including all its side effects, before
the one on the right, but that guarantee doesn't matter because the
expressions in each pair don't interact with each other, and the code
makes no use of the result of either comma expression. Therefore, they
could just as easily have occurred in the opposite order, which was the
point of my re-write. I apologize for messing up the point I was making
by doing the re-write incorrectly.

Let me put that another way: the original code was equivalent to

  ent = master, count = 0;
  while(ent)
     count++, ent = ent->chain;

which in turn is equivalent to

  ent = master;
  count = 0;
  while(ent){
     count++;
     ent = ent->chain;
  }

> As for the comma operator, what does the standard have to say about
> how the comma operator works in this context? Or in ANY context for
> that matter?

I see that Keith has quoted the relevant part of the standard for you.
Do you understand that citation? I see a couple of points that might be
unclear to a newbie, such as "evaluated as a void expression" and
"sequence point". Feel free to ask about anything that seems unclear.

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

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

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

csiph-web