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

#150737

On Sunday, March 22, 2020 at 12:46:17 PM UTC-4, Bart wrote:
...
> If you think taking an unrelated assortment of declarations, 
> initialisations, expressions and conditional expressions, and sticking 
> them all inside a pair of parentheses delimited by a mix of commas and 
> semicolons, preferally all on one line, is good practice, then I suspect 
> /you're/ the one who's trolling.

No one is suggesting anything of the kind. The purpose of the for
statement is not to put together unrelated things, but to put together
things that are all related to each other by the role they play in
controlling the loop. There are other ways to use a for-statement that
have well-defined behavior; anything can be abused. But no one is
suggesting that you should actually write code which takes advantage
of that fact.

> See also MISRA 2004 rule 13.5 (don't know if later versions have the 
> same rule number):
> 
> "The three expressions of a for statement shall be concerned only
> with loop control.
> 
> The three expressions of a for statement shall be used only for these 
> purposes:
> 
> First expression Initialising the loop counter (i in the following example)
> 
> Second expression Shall include testing the loop counter (i), and 
> optionally other
> loop control variables (flag)
> 
> Third expression Increment or decrement of the loop counter (i)"
> 
> Think about why they might have such a rule. And think about what 
> structured programming is supposed to mean.

I have. The first part of the rule makes perfect sense to me, and
matches exactly my own recommendations. The last part of the rule is
typical MISRA over-reaching, imposing unnecessary restrictions with bad
justifications. I recommend that you write code that obeys those
restrictions, but I wouldn't recommend that to any competent C programmer.

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

#150753

On 22/03/2020 18:42, James Kuyper wrote:
> On Sunday, March 22, 2020 at 12:46:17 PM UTC-4, Bart wrote:
> ...
>> If you think taking an unrelated assortment of declarations,
>> initialisations, expressions and conditional expressions, and sticking
>> them all inside a pair of parentheses delimited by a mix of commas and
>> semicolons, preferally all on one line, is good practice, then I suspect
>> /you're/ the one who's trolling.
> 
> No one is suggesting anything of the kind. The purpose of the for
> statement is not to put together unrelated things,

But that's what happens.

The OP had a particular algorithm to executed, and managed to put all 5 
necessary elements of it into the (...) of one for-header. No body was 
needed (which additionally means that if the following ; was omitted, it 
could do unexpected things).

The pattern was this:

     for (A, B; C; D, E);

The while loop version I devised was this:

     A;
     B;
     while (C) {
         D;
         E;       // (I used E;D, but either will work)
     }

Now, we've finally arrived in the 1970s with its new-fangled 'structured 
programming'! Ie. Algol not Fortran. Although even Fortran code would be 
written vertically not horizontally.


>> First expression Initialising the loop counter (i in the following example)

>> Think about why they might have such a rule. And think about what
>> structured programming is supposed to mean.
> 
> I have. The first part of the rule makes perfect sense to me, and
> matches exactly my own recommendations. The last part of the rule is
> typical MISRA over-reaching, imposing unnecessary restrictions with bad
> justifications. I recommend that you write code that obeys those
> restrictions, but I wouldn't recommend that to any competent C programmer.

Well, look at the fuss in this thread about what exactly comma operators 
inside for-loop headers mean.

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

#150755

On Sunday, March 22, 2020 at 6:03:19 PM UTC-4, Bart wrote:
> On 22/03/2020 18:42, James Kuyper wrote:
> > On Sunday, March 22, 2020 at 12:46:17 PM UTC-4, Bart wrote:
> > ...
> >> If you think taking an unrelated assortment of declarations,
> >> initialisations, expressions and conditional expressions, and sticking
> >> them all inside a pair of parentheses delimited by a mix of commas and
> >> semicolons, preferally all on one line, is good practice, then I suspect
> >> /you're/ the one who's trolling.
> > 
> > No one is suggesting anything of the kind. The purpose of the for
> > statement is not to put together unrelated things,
> 
> But that's what happens.

Not very often, not in my experience. You've voiced opposition to cases
where they are, in fact, all related to loop control, such as

    for(Node *node = root; node; node = node->next)

or

    for(unsigned mask=0x8000; mask; mask >= 1)

so it's clear that it's not the lack of relation that you're opposed to,
but the failure to be related in ways that you consider acceptable.
 
Any feature of the language can be misused, including a=b. Are you going
to oppose the use of the assignment operator because some people use it
when they shouldn't?

The for-statement, when properly used, encourages better programming by
reminding you to think about the different parts of the loop control at
the same time, separate from the body of the loop.

> The OP had a particular algorithm to executed, and managed to put all 5 
> necessary elements of it into the (...) of one for-header. No body was 
> needed (which additionally means that if the following ; was omitted, it 
> could do unexpected things).

And he's sufficiently a newbie that he didn't realize that what he did
with the "ent = master" expression was horribly wrong. His code cannot
be used an example of what competent experienced C programmers do.

...
> >> Think about why they might have such a rule. And think about what
> >> structured programming is supposed to mean.
> > 
> > I have. The first part of the rule makes perfect sense to me, and
> > matches exactly my own recommendations. The last part of the rule is
> > typical MISRA over-reaching, imposing unnecessary restrictions with bad
> > justifications. I recommend that you write code that obeys those
> > restrictions, but I wouldn't recommend that to any competent C programmer.
> 
> Well, look at the fuss in this thread about what exactly comma operators 
> inside for-loop headers mean.

And what do you take from that fuss? It's still not clear to me why the
subject line refers to the comma operator, nor why he brought it up in
his first message. His most recent post referring to the comma operator
still implies that there's something connected to the comma operator
that he's confused about, but I still haven't figured out what it is.

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

#150759

On 23/03/2020 06:51, James Kuyper wrote:
> On Sunday, March 22, 2020 at 6:03:19 PM UTC-4, Bart wrote:
>> On 22/03/2020 18:42, James Kuyper wrote:
>>> On Sunday, March 22, 2020 at 12:46:17 PM UTC-4, Bart wrote:
>>> ...
>>>> If you think taking an unrelated assortment of declarations,
>>>> initialisations, expressions and conditional expressions, and sticking
>>>> them all inside a pair of parentheses delimited by a mix of commas and
>>>> semicolons, preferally all on one line, is good practice, then I suspect
>>>> /you're/ the one who's trolling.
>>>
>>> No one is suggesting anything of the kind. The purpose of the for
>>> statement is not to put together unrelated things,
>>
>> But that's what happens.
> 
> Not very often, not in my experience. You've voiced opposition to cases
> where they are, in fact, all related to loop control, such as
> 
>      for(Node *node = root; node; node = node->next)
> 
> or
> 
>      for(unsigned mask=0x8000; mask; mask >= 1)
> 
> so it's clear that it's not the lack of relation that you're opposed to,
> but the failure to be related in ways that you consider acceptable.

The way MISRA described the 3 expressions of a for-statement suggested 
it was leaning heavily in favour of them being used for an interative index.

My own experience of for-loops in languages that haven't adopted C's 
for(a;b;c) approach is that they are purely iterative (or more recently, 
iterate over the values of an object).

For any other kinds of loops controlled by an arbitrary condition, they 
might use while or repeat loops. And actually, none of those languages 
seemed to have had a pressing need for C's flexible for-loop.

> Any feature of the language can be misused, including a=b. Are you going
> to oppose the use of the assignment operator because some people use it
> when they shouldn't?

We need assignment operators, since using memcpy everywhere is unviable. 
We don't need a way of cramming the five parts of an algorithm into one 
pair of parentheses. (Leave that to Python coders.)


> The for-statement, when properly used, encourages better programming by
> reminding you to think about the different parts of the loop control at
> the same time, separate from the body of the loop.

It also allows you to make more mistakes; does:

     for (i=0; i<=N; ++j)

contain 0, 1 or 2 typos? You can't be sure.

(A summary of for-loops over time and by language is here: 
https://en.wikipedia.org/wiki/For_loop

Of the 30-odd languages mentioned, only about 5, in addition to C/C++, 
use a blatant copy of C's for-loop.

These are the ones where a simple iteration needs 4 additional (and 
error prone) pieces of information that the others largely don't because 
the language can figure them out. Namely, two extra references to the 
loop variable, the operator to be used to compare against a limit, and 
how to increment the loop variable.)


>> The OP had a particular algorithm to executed, and managed to put all 5
>> necessary elements of it into the (...) of one for-header. No body was
>> needed (which additionally means that if the following ; was omitted, it
>> could do unexpected things).
> 
> And he's sufficiently a newbie that he didn't realize that what he did
> with the "ent = master" expression was horribly wrong. His code cannot
> be used an example of what competent experienced C programmers do.

You're saying that a 'newbie' can find a for-loop more confusing than an 
equivalent while-loop.

I'm not sure that counts as an advantage.

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

#150760

On Monday, 23 March 2020 14:37:38 UTC, Bart  wrote:
> 
> The way MISRA described the 3 expressions of a for-statement suggested 
> it was leaning heavily in favour of them being used for an interative index.
> 
> My own experience of for-loops in languages that haven't adopted C's 
> for(a;b;c) approach is that they are purely iterative (or more recently, 
> iterate over the values of an object).
> 
> For any other kinds of loops controlled by an arbitrary condition, they 
> might use while or repeat loops. And actually, none of those languages 
> seemed to have had a pressing need for C's flexible for-loop.
> 
Iterating over the values isn't flexible enough, as you often need the
index, to access elements immediately adjacent, or for parallel arrays.
On the other hand, allowing any mixture of start, termination, and
increment options is too flexible. Normally mixed conditions should be 
recast as  while loops. For loops are really designed for use with an 
index variable and a termination condition which is fixed at loop entry. 

I do occaisonally use a for loop for a linked list, however.

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

#150761

Le 23/03/2020 à 16:41, Malcolm McLean a écrit :
>
> Iterating over the values isn't flexible enough, as you often need the
> index, to access elements immediately adjacent, or for parallel arrays.

Yep.

> On the other hand, allowing any mixture of start, termination, and
> increment options is too flexible.

It's the flexibility you get with C in general, the goal of which is to 
be flexible while being the simplest possible.

Some languages allow the same kind of flexibility with similar "for" 
loops, but with "true" iterators, which makes things a bit clearer and 
less risky, but not necessarily that much easier to read. Obviously C 
doesn't have any kind of iterators per se, so it's all to be done 
"manually".

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

#150762

On 23/03/2020 15:41, Malcolm McLean wrote:
> On Monday, 23 March 2020 14:37:38 UTC, Bart  wrote:
>>
>> The way MISRA described the 3 expressions of a for-statement suggested
>> it was leaning heavily in favour of them being used for an interative index.
>>
>> My own experience of for-loops in languages that haven't adopted C's
>> for(a;b;c) approach is that they are purely iterative (or more recently,
>> iterate over the values of an object).
>>
>> For any other kinds of loops controlled by an arbitrary condition, they
>> might use while or repeat loops. And actually, none of those languages
>> seemed to have had a pressing need for C's flexible for-loop.
>>
> Iterating over the values isn't flexible enough, as you often need the
> index, to access elements immediately adjacent, or for parallel arrays.

There are various schemes employed to obtain the index with other 
languages. My own (for my recently added 'forall' in my static language) 
just requires that you provide an extra index variable:

     []real A := (10.1, 20.2, 30.3, 40.4)

     forall i,x in A do
         println i,x, i.typestr, x.typestr
     od

Output is:

     1 10.100000 i64 r64
     2 20.200000 i64 r64
     3 30.300000 i64 r64
     4 40.400000 i64 r64

'i' and 'x' don't need declaring; their types are inferred (actually I 
wasn't sure until I tried it that this would work for 'x'.).

'i' is also readonly (I'm working on making 'x' readonly but currently 
the implicit assignment to x is via user-code). The compiler can 
increment 'i'; user-code can't. (Unless you declare them outside the loop.)

However I don't support parallel arrays (not directly). And it doesn't 
support reference versions of 'x' so that you can modify the array via x 
(you need A[i]).

But for now these 'basics' are sufficient, especially when you look at 
the C version of this example which is:

     double A[] = {10.1, 20.2, 30.3, 40.4};
     double x;

     for (int i=0; i<(sizeof(A)/sizeof(A[0])); ++i) {
         x = A[i];
         printf("%d %f i32 f64\n", i, x);
     }

Differences:

- x can't be declared in the for-header as it is not int

- i is not 'const' so could be modified in the loop

- The limit needs a constant expression that is tied to that specific
   kind of array

- i and x both need to be explicitly declared

- Requires format codes which also are tied to the types of i and x so
   need to be maintained

- There is no way to do '.typestr' so that output is hard-coded.

- 'i' occurs 5 times in the C, 2 times in my version (excluding
    i.typestr which C doesn't support); 'x' occurs 3 times rather than 2

- The "<" and "++" need to be explicitly specified

(C++ provides some more advanced features, but that goes to show that 
C's flexibility in its for-loop isn't really that useful; more a hassle 
as you have to literally specify everything.)

> On the other hand, allowing any mixture of start, termination, and
> increment options is too flexible. Normally mixed conditions should be
> recast as  while loops. For loops are really designed for use with an
> index variable and a termination condition which is fixed at loop entry.

No one here is interested in hearing that!

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

#150764

Bart <bc@freeuk.com> writes:

> On 23/03/2020 15:41, Malcolm McLean wrote:
<cut>
>> On the other hand, allowing any mixture of start, termination, and
>> increment options is too flexible. Normally mixed conditions should be
>> recast as  while loops. For loops are really designed for use with an
>> index variable and a termination condition which is fixed at loop entry.
>
> No one here is interested in hearing that!

Or, more likely, no one here wants to ear that /again./  I've been
hearing that for about 37 years, and I've processed it already.

-- 
Ben.

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

#150765

On Monday, 23 March 2020 16:48:58 UTC, Ben Bacarisse  wrote:
> Bart <bc@freeuk.com> writes:
> 
> > On 23/03/2020 15:41, Malcolm McLean wrote:
> <cut>
> >> On the other hand, allowing any mixture of start, termination, and
> >> increment options is too flexible. Normally mixed conditions should be
> >> recast as  while loops. For loops are really designed for use with an
> >> index variable and a termination condition which is fixed at loop entry.
> >
> > No one here is interested in hearing that!
> 
> Or, more likely, no one here wants to ear that /again./  I've been
> hearing that for about 37 years, and I've processed it already.
> 
It's a fairly obvious criticism to make of C's for loop. 

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

#150769

On 23/03/2020 17:53, Malcolm McLean wrote:
> On Monday, 23 March 2020 16:48:58 UTC, Ben Bacarisse  wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 23/03/2020 15:41, Malcolm McLean wrote:
>> <cut>
>>>> On the other hand, allowing any mixture of start, termination, and
>>>> increment options is too flexible. Normally mixed conditions should be
>>>> recast as  while loops. For loops are really designed for use with an
>>>> index variable and a termination condition which is fixed at loop entry.
>>>
>>> No one here is interested in hearing that!
>>
>> Or, more likely, no one here wants to ear that /again./  I've been
>> hearing that for about 37 years, and I've processed it already.
>>
> It's a fairly obvious criticism to make of C's for loop.
> 

Since it's obvious, anyone who uses C already knows that its flexibility 
comes with risks.

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

#150773

On Monday, 23 March 2020 17:59:16 UTC, David Brown  wrote:
> On 23/03/2020 17:53, Malcolm McLean wrote:
> > On Monday, 23 March 2020 16:48:58 UTC, Ben Bacarisse  wrote:
> >> Bart <bc@freeuk.com> writes:
> >>
> >>> On 23/03/2020 15:41, Malcolm McLean wrote:
> >> <cut>
> >>>> On the other hand, allowing any mixture of start, termination, and
> >>>> increment options is too flexible. Normally mixed conditions should be
> >>>> recast as  while loops. For loops are really designed for use with an
> >>>> index variable and a termination condition which is fixed at loop entry.
> >>>
> >>> No one here is interested in hearing that!
> >>
> >> Or, more likely, no one here wants to ear that /again./  I've been
> >> hearing that for about 37 years, and I've processed it already.
> >>
> > It's a fairly obvious criticism to make of C's for loop.
> > 
> 
> Since it's obvious, anyone who uses C already knows that its flexibility 
> comes with risks.
>
I'm pretty sure that Denis Ritchie designed the for loop with the
goal of making the grammar easy to write. A less flexible and thus
less abusable for loop syntax would need more complicated rules.
 

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

#150775

On 23/03/2020 18:23, Malcolm McLean wrote:
> On Monday, 23 March 2020 17:59:16 UTC, David Brown  wrote:
>> On 23/03/2020 17:53, Malcolm McLean wrote:
>>> On Monday, 23 March 2020 16:48:58 UTC, Ben Bacarisse  wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>> On 23/03/2020 15:41, Malcolm McLean wrote:
>>>> <cut>
>>>>>> On the other hand, allowing any mixture of start, termination, and
>>>>>> increment options is too flexible. Normally mixed conditions should be
>>>>>> recast as  while loops. For loops are really designed for use with an
>>>>>> index variable and a termination condition which is fixed at loop entry.
>>>>>
>>>>> No one here is interested in hearing that!
>>>>
>>>> Or, more likely, no one here wants to ear that /again./  I've been
>>>> hearing that for about 37 years, and I've processed it already.
>>>>
>>> It's a fairly obvious criticism to make of C's for loop.
>>>
>>
>> Since it's obvious, anyone who uses C already knows that its flexibility
>> comes with risks.
>>
> I'm pretty sure that Denis Ritchie designed the for loop with the
> goal of making the grammar easy to write. A less flexible and thus
> less abusable for loop syntax would need more complicated rules.
>   
> 

More likely making the compiler easier.

I can implement everything to do with C99's for-loop in 135 lines of 
code; or 90 lines if you exclude declarations as in the original.

By contrast, the version in my language (although split over 1/2 more 
passes) is 350 lines.

This is with basic 'for' (which includes iterating over bounds using 
'for i in A' when A is an array or slice, and supporting extra loop 
controls with nested loops), but not 'forall'.

C's for is simpler because you basically do the compiler's job for it, 
and have to supply much of the code that would normally be generated by 
the compiler.

However, my 200 extra lines are only written once in the compiler. But 
all the extra stuff that you need in a C for-header, has to be written 
1000s of times by each of a million programmers.

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

#150782

On Monday, March 23, 2020 at 3:51:28 PM UTC-4, Bart wrote:
> On 23/03/2020 18:23, Malcolm McLean wrote:
...
> > I'm pretty sure that Denis Ritchie designed the for loop with the
> > goal of making the grammar easy to write. A less flexible and thus
> > less abusable for loop syntax would need more complicated rules.
> >   
> > 
> 
> More likely making the compiler easier.

He designed it to make coding correctly easier, by packaging together
the different parts of the loop control. It was intended, from the
beginning, to be as flexible as it is, to allow for more complicated
kinds of loop control. What was unintentional, was that it would also
allow things unrelated to loop control - a requirement that it only be
used for loop control while still allowing the full intended amount of flexibility would have been both hard to document and hard to
implement.

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

#150776

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> I'm pretty sure that Denis Ritchie designed the for loop with the
> goal of making the grammar easy to write. A less flexible and thus
> less abusable for loop syntax would need more complicated rules.

I'm pretty sure that Dennis Ritchie had no objection to using for loops
for things other than arithmetic progressions.  Quoting K&R2:

    The for is preferable [to while] when there is a simple
    initialization and increment, since it keeps the loop control
    statements close together and visible at the top of the loop.
    This is most obvious in
        for (i = 0; i < n; i++)
            ...
    [...]
    Because the components of the for are arbitrary expressions,
    for loops are not restricted to arithmetic progressions.
    Nonetheless, it's bad style to force unrelated computations
    into the initialization and increment of a for, which are better
    reserved for loop control operations.

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

#150778

On Monday, 23 March 2020 20:09:42 UTC, Keith Thompson  wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> [...]
> > I'm pretty sure that Denis Ritchie designed the for loop with the
> > goal of making the grammar easy to write. A less flexible and thus
> > less abusable for loop syntax would need more complicated rules.
> 
> I'm pretty sure that Dennis Ritchie had no objection to using for loops
> for things other than arithmetic progressions.  Quoting K&R2:
> 
>     The for is preferable [to while] when there is a simple
>     initialization and increment, since it keeps the loop control
>     statements close together and visible at the top of the loop.
>     This is most obvious in
>         for (i = 0; i < n; i++)
>             ...
>     [...]
>     Because the components of the for are arbitrary expressions,
>     for loops are not restricted to arithmetic progressions.
>     Nonetheless, it's bad style to force unrelated computations
>     into the initialization and increment of a for, which are better
>     reserved for loop control operations.
> 
Well the secnd quote is an admision that the C for loop is too flexible.

How best to restrict it is another issue. For instance to iterate over
a linked list

for (ptr = head, ptr != NULL; ptr = ptr->next)

seems reasonable to me, but isn't an arithmetical progression.

On the other hand, I wouldn't like a function call in the increment
statement. 

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

#150779

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Monday, 23 March 2020 20:09:42 UTC, Keith Thompson  wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> [...]
>> > I'm pretty sure that Denis Ritchie designed the for loop with the
>> > goal of making the grammar easy to write. A less flexible and thus
>> > less abusable for loop syntax would need more complicated rules.
>> 
>> I'm pretty sure that Dennis Ritchie had no objection to using for loops
>> for things other than arithmetic progressions.  Quoting K&R2:
>> 
>>     The for is preferable [to while] when there is a simple
>>     initialization and increment, since it keeps the loop control
>>     statements close together and visible at the top of the loop.
>>     This is most obvious in
>>         for (i = 0; i < n; i++)
>>             ...
>>     [...]
>>     Because the components of the for are arbitrary expressions,
>>     for loops are not restricted to arithmetic progressions.
>>     Nonetheless, it's bad style to force unrelated computations
>>     into the initialization and increment of a for, which are better
>>     reserved for loop control operations.
>> 
>Well the secnd quote is an admision that the C for loop is too flexible.

No, it is a personal stylistic opinion.

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

#150780

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, 23 March 2020 20:09:42 UTC, Keith Thompson  wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> [...]
>> > I'm pretty sure that Denis Ritchie designed the for loop with the
>> > goal of making the grammar easy to write. A less flexible and thus
>> > less abusable for loop syntax would need more complicated rules.
>> 
>> I'm pretty sure that Dennis Ritchie had no objection to using for loops
>> for things other than arithmetic progressions.  Quoting K&R2:
>> 
>>     The for is preferable [to while] when there is a simple
>>     initialization and increment, since it keeps the loop control
>>     statements close together and visible at the top of the loop.
>>     This is most obvious in
>>         for (i = 0; i < n; i++)
>>             ...
>>     [...]
>>     Because the components of the for are arbitrary expressions,
>>     for loops are not restricted to arithmetic progressions.
>>     Nonetheless, it's bad style to force unrelated computations
>>     into the initialization and increment of a for, which are better
>>     reserved for loop control operations.
>> 
> Well the secnd quote is an admision that the C for loop is too flexible.

No, it's an admission that any language construct can be abused.
Applying arbitrary restrictions would be pointless.  There's no
way for a compiler to know that a computation in a for loop is
"unrelated", and no set of restrictions that would avoid abuse
without restricting some sensible usage.

> How best to restrict it is another issue. For instance to iterate over
> a linked list
>
> for (ptr = head, ptr != NULL; ptr = ptr->next)

(That comma should be a semicolon, of course.)

> seems reasonable to me, but isn't an arithmetical progression.
>
> On the other hand, I wouldn't like a function call in the increment
> statement. 

This:
    for (foo = get_head(); foo != NULL; foo = get_next(foo)
seems perfectly reasonable to me.  Again, any arbitrary restriction
will prohibit useful code.

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

#150785

On Monday, 23 March 2020 20:56:01 UTC, Keith Thompson  wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> > On Monday, 23 March 2020 20:09:42 UTC, Keith Thompson  wrote:
> >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >> [...]
> >> > I'm pretty sure that Denis Ritchie designed the for loop with the
> >> > goal of making the grammar easy to write. A less flexible and thus
> >> > less abusable for loop syntax would need more complicated rules.
> >> 
> >> I'm pretty sure that Dennis Ritchie had no objection to using for loops
> >> for things other than arithmetic progressions.  Quoting K&R2:
> >> 
> >>     The for is preferable [to while] when there is a simple
> >>     initialization and increment, since it keeps the loop control
> >>     statements close together and visible at the top of the loop.
> >>     This is most obvious in
> >>         for (i = 0; i < n; i++)
> >>             ...
> >>     [...]
> >>     Because the components of the for are arbitrary expressions,
> >>     for loops are not restricted to arithmetic progressions.
> >>     Nonetheless, it's bad style to force unrelated computations
> >>     into the initialization and increment of a for, which are better
> >>     reserved for loop control operations.
> >> 
> > Well the secnd quote is an admision that the C for loop is too flexible.
> 
> No, it's an admission that any language construct can be abused.
> Applying arbitrary restrictions would be pointless.  There's no
> way for a compiler to know that a computation in a for loop is
> "unrelated", and no set of restrictions that would avoid abuse
> without restricting some sensible usage.
> 
To enfore Ritchie's style rules you need a for loop of the form

for indexvar = initalisation; indexvar != terminal; indexvar = interateexpression

the left hand side of each portion of the loop is constrained to be
the same variable. You'd enforce that by having a slightly different
syntax, rather than by adding context-dependent grammar rules.

The compiler can do that easily enough. 

Arguably that is too strict, because sometimes you have for loops with
two control variables. That doesn't really count as "forcing
unrelated computations into the initialisation and increment of a
for". Though in my experience it's usually hard to follow such
loops.
 

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

#150787

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, 23 March 2020 20:56:01 UTC, Keith Thompson  wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
>> > Well the secnd quote is an admision that the C for loop is too flexible.
>> 
>> No, it's an admission that any language construct can be abused.
>> Applying arbitrary restrictions would be pointless.  There's no
>> way for a compiler to know that a computation in a for loop is
>> "unrelated", and no set of restrictions that would avoid abuse
>> without restricting some sensible usage.
>> 
> To enfore Ritchie's style rules you need a for loop of the form
>
> for indexvar = initalisation; indexvar != terminal; indexvar = interateexpression
>
> the left hand side of each portion of the loop is constrained to be
> the same variable. You'd enforce that by having a slightly different
> syntax, rather than by adding context-dependent grammar rules.
>
> The compiler can do that easily enough. 

You want to require the second expression to be a "!=" comparison?  You
want to ban "i < N"?

> Arguably that is too strict, because sometimes you have for loops with
> two control variables. That doesn't really count as "forcing
> unrelated computations into the initialisation and increment of a
> for". Though in my experience it's usually hard to follow such
> loops.

Yeah, that's too strict.  It's fine the way it is.

If somebody came up with a more restrictive kind of loop that covered
most cases and was less error-prone, I might not object to adding it to
a future version of the language -- *in addition to* C's existing for
loop, not replacing it.

Bart has objected here to having to write "i" three times in

    for (i = 0; i < N; i++)

He does have a bit of a point, since writing "j" rather than "i" is a
plausible error that a compiler is unlikely to catch.

That could be addressed with a macro:

    #define BARTFOR(var, lower, upper) for (var = (first), var < (last); var++)
    ...
    BARTFOR(i, 0, N)

I wouldn't use it myself, but I probably would if it were a standard
language feature.

The first step in getting such a feature added to the language would be
for some implementation to provide it as an extension.

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

#150789

On Monday, 23 March 2020 23:27:49 UTC, Keith Thompson  wrote:
>
> >
> > The compiler can do that easily enough. 
> 
> You want to require the second expression to be a "!=" comparison?  You
> want to ban "i < N"?
> 
For some reason the convention is to write

for (i=0; i < N; i++ )

rather than

for (i=0; i != N; i++ )

which has the same effect, unless you are playing games with the index 
variable in the loop body.

But if we force the left hand side of the comparison to be "i", which it 
almost always is, unless the for syntax is being abused, then the easiest
way is to alter the syntax so that the symbol "i" appears only once.

If we allow  i < N, then that means writing for(i=0; < N ... which looks
very odd. If we change the condition from a loop continuation condition
into a terminal condition, we can write for (i=0;N; ... ) which is
much more acceptable.
>
> If somebody came up with a more restrictive kind of loop that covered
> most cases and was less error-prone, I might not object to adding it to
> a future version of the language -- *in addition to* C's existing for
> loop, not replacing it.
>
The ship has sailed, and now you'd have to support old style for loops 
for a very long time, for backwards compatibility. But if we were
designing C from scratch, we could reasonably have a less flexible
for loop. If people want complex conditions rather than simple iteration,
usually over an array, they can use "while".
> 
> Bart has objected here to having to write "i" three times in
> 
>     for (i = 0; i < N; i++)
> 
> He does have a bit of a point, since writing "j" rather than "i" is a
> plausible error that a compiler is unlikely to catch.
> 
> That could be addressed with a macro:
> 
>     #define BARTFOR(var, lower, upper) for (var = (first), var < (last); var++)
>     ...
>     BARTFOR(i, 0, N)
> 
> I wouldn't use it myself, but I probably would if it were a standard
> language feature.
> 
> The first step in getting such a feature added to the language would be
> for some implementation to provide it as an extension.
> 
In other languages there is a fashion for providing different ways
of iterating over an array, or other "collection". 

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

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

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

csiph-web