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

#150816

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> David Brown <david.brown@hesbynett.no> writes:
<cut>
>> The idea here is to lock the loop variable inside the loop, so that it
>> can only be changed in the iterator part of the for-statement.
>
> There is precedent for something similar in Ada.  An Ada for loop can
> look like this, for example:
>
>     for I in 1..10 loop
>         -- ...
>     end loop;
>
> I is local to each iteration of the loop, and is treated as read-only.

and Algol 68 does (did?) the same thing.

-- 
Ben.

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

#150788

On Monday, March 23, 2020 at 6:43:58 PM UTC-4, Malcolm McLean wrote:
> 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:
...
> > >> I'm pretty sure that Dennis Ritchie had no objection to using for loops
> > >> for things other than arithmetic progressions.  Quoting K&R2:
...
> > >>     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.
...
> To enfore Ritchie's style rules you need a for loop of the form
> 
> for indexvar = initalisation; indexvar != terminal; indexvar = interateexpression

How in the world did you derive such a restricted version of the for
statement from Ritchie's comments about bad style? There's lots of ways
to write code that is solely concerted with loop control that can't even
come close to fitting into those restrictions. Even Bart's beloved
simple iterator for(i=0; i<N; i++) doesn't fit those restrictions.

I think that there should be some state somewhere that is initialized by
the initializer, checked by the condition expression, and changed (at
least conditionally) by the increment expression, but that's as far as
I'd be willing to restrict for statements. That state might be stored
outside the current translation unit (and maybe even outside of the
program itself, in a file or device), with the initializer, condition,
and increment being connected to that state only through function calls.
This implies that such restrictions could not be implemented as
constraints.

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

#150792

On 23/03/2020 21:20, Malcolm McLean wrote:
> 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.
> 

There is no way to legislate style.  A guide book can provide advice, 
but it is up to programmers to write sensible code.  This is /always/ 
the case - it is not something special about C or C's "for" loops.  No 
matter how restricted a language is, you can't write rules that 
eliminate all bad code style.

Have a look at <https://thedailywtf.com/> to see some examples.  You 
don't need C's flexibility to write complete gibberish that happens to work.

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

#150771

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

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

In the proper academic sense of the word, yes.

-- 
Ben.

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

#150763

On Monday, March 23, 2020 at 10:37:38 AM UTC-4, Bart wrote:
> 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.

Yes, it appears that MISRA shares your preferences. From what I've seen,\
bad decisions like that are typical of MISRA.

In case you haven't gotten the message yet, let me say this more
explicitly - saying that MISRA agrees with you does NOT improve your
case, at least not as far as I'm concerned.

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

It's a convenience feature, improving the maintainability and
readability of the code when used properly - it's never "needed", only
useful.

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

No - the mistake he made was while writing the while-loop. If he'd
thought about it carefully, he should have realized that the while loop,
as he wrote it, didn't make any sense. The fact that it didn't make
sense was completely independent of the fact that it is also a mis-
translation of the for loop. Except, of course, that the for loop was
working code (however badly written), and therefore would not contain
any error that blatant. Code that is basically working correctly can
still have bugs, but they are necessarily far subtler than that one.

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

#150770

On 23/03/2020 17:32, James Kuyper wrote:
> On Monday, March 23, 2020 at 10:37:38 AM UTC-4, Bart wrote:
>> 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.
> 
> Yes, it appears that MISRA shares your preferences. From what I've seen,\
> bad decisions like that are typical of MISRA.
> 
> In case you haven't gotten the message yet, let me say this more
> explicitly - saying that MISRA agrees with you does NOT improve your
> case, at least not as far as I'm concerned.

Saying MISRA agrees with you shows that you are not alone in your 
opinion, so it is not entirely irrelevant.  But it doesn't mean the 
opinion is shared by many, or well thought through.  In many cases, 
MISRA take a good idea and then extends it to the ridiculous.  A 
recurring theme is avoiding things that might be a problem on poor 
quality tools, or where mistakes might not be easily spotted by poor 
quality tools.  This has always struck me as an absurd attitude - rule 
one of a coding standard for safety-critical systems should be "get good 
tools, and learn how to use them".

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

#150766

On 3/23/20 10:37 AM, Bart wrote:
> 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.
> 

One BIG thing to remember about the design of C, C was designed to be
used by the skilled programmer, not the beginner. C trust the programmer.

With C, it is easy to make some mistakes that can cause problems, that's
ok, C expects the programmer to be able to debug the program and find
the issues.

I exchange for trusting the programmer, C is able to generate efficient
programs, even with a somewhat simple compiler.

There is a reason C has been the staple language for systems programs
for decades. It may be getting a bit less in recent years as machines
have gotten faster and bigger so efficiency isn't as important, and
programs have gotten bigger so some higher level abstractions become
more useful, but it still is a major share.

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

#150767

On Monday, 23 March 2020 17:23:28 UTC, Richard Damon  wrote:
> 
> One BIG thing to remember about the design of C, C was designed to be
> used by the skilled programmer, not the beginner. C trust the programmer.
> 
> With C, it is easy to make some mistakes that can cause problems, that's
> ok, C expects the programmer to be able to debug the program and find
> the issues.
> 
Except it's not the case. Software was and is notorious for not performing
correctly. The issue isn't basically the quality of the programmers, often
they are highly paid, and with degrees from good universities. 

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

#150768

Le 23/03/2020 à 18:33, Malcolm McLean a écrit :
> (..) The issue isn't basically the quality of the programmers, often
> they are highly paid, and with degrees from good universities.

Neither of which makes them inherently good. :)

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

#150772

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Monday, 23 March 2020 17:23:28 UTC, Richard Damon  wrote:
>> 
>> One BIG thing to remember about the design of C, C was designed to be
>> used by the skilled programmer, not the beginner. C trust the programmer.
>> 
>> With C, it is easy to make some mistakes that can cause problems, that's
>> ok, C expects the programmer to be able to debug the program and find
>> the issues.
>> 
> Except it's not the case. Software was and is notorious for not performing
> correctly. The issue isn't basically the quality of the programmers, often
> they are highly paid, and with degrees from good universities.

RD did not say highly paid nor did he say with degrees from good
universities (whatever they are).  He said skilled.  C was designed to
be used by a small team at Bell Labs deigning an OS and writing other
system software.  Once it escaped that environment, it was all set up to
become a hostage to it's own success.

-- 
Ben.

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

#150783

On 2020-03-23, Bart <bc@freeuk.com> wrote:
> 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.

Doesn't that hold for any language construct?
Take a simple assignment:

  h = 2;

This could also contain 0, 1 or 2 typos. Perhaps the author meant

  g = 1;

but accidently moved their left hand one position to the left on a QWERTY keyboard.

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

#150786

On 23/03/2020 22:29, Ike Naar wrote:
> On 2020-03-23, Bart <bc@freeuk.com> wrote:
>> 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.
> 
> Doesn't that hold for any language construct?
> Take a simple assignment:
> 
>    h = 2;
> 
> This could also contain 0, 1 or 2 typos. Perhaps the author meant
> 
>    g = 1;
> 
> but accidently moved their left hand one position to the left on a QWERTY keyboard.

Yes, you can make an error each time you write a variable name. But the 
for-loop /demands/ that you write the index variable 3 times instead of 
once. I've been bitten by this quite a few times when you start with the 
one loop, duplicate the line because you need a nested loop, then mess 
up changing all the i's into j's.

The second "i", the third "i", the "<" and the "++" are all extra things 
that someone can get wrong. And that can then obscure whether someone 
intended a common 'for i in 0..N-1' loop or not.

(Notice the plain syntax I used there. Why don't more languages use 
plain syntax?)

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

#150726

In article <N4LdG.57428$WT2.44415@fx06.am4>, Bart  <bc@freeuk.com> wrote:

>In that case, why favour FOR over WHILE, rather than the other way 
>around? Because it's easier to cram more stuff on one line?

Because it puts all the information about the loop in one place.

-- Richard

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

#150729

On Sun, 22 Mar 2020 15:55:14 +0100, felix@palmen-it.de (Felix Palmen)
wrote:

>* Bart <bc@freeuk.com>:
>> You seem to be forgetting that C HAS a while-loop.
>
>You seem to be forgetting that this is actually *the same*¹
>
>    statement1;
>    while (condition) {
>        [...]
>        statement2;
>    }
>
>is always *exactly* the same as:
>
>    for (statement1; condition; statement2) {
>        [...]
>    }

This is almost always true, except in one circumstance: a while
statement requires a condition expression, but a for statement does
not. "for(;;){}" is common shorthand for an infinite loop. There is
probably a historical reason that for-loops have a default of 'true'
for an empty loop-condition, but I don't know the details. It must
have made sense at the time.

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

#150758

On Sunday, 22 March 2020 16:16:35 UTC, Scott  wrote:
> On Sun, 22 Mar 2020 15:55:14 +0100, felix@palmen-it.de (Felix Palmen)
> wrote:
> 
> >* Bart <bc@freeuk.com>:
> >> You seem to be forgetting that C HAS a while-loop.
> >
> >You seem to be forgetting that this is actually *the same*¹
> >
> >    statement1;
> >    while (condition) {
> >        [...]
> >        statement2;
> >    }
> >
> >is always *exactly* the same as:
> >
> >    for (statement1; condition; statement2) {
> >        [...]
> >    }
> 
> This is almost always true, except in one circumstance: a while
> statement requires a condition expression, but a for statement does
> not. "for(;;){}" is common shorthand for an infinite loop. There is
> probably a historical reason that for-loops have a default of 'true'
> for an empty loop-condition, but I don't know the details. It must
> have made sense at the time.
>
I'd the guess the reason is that you can write

for (i=0; ; i++)
{
   /* do stuff with i <= the sentinel value */ 
   if(array[i] == SENTINEL)
     break;
   /* do stuff with i < the sentinel value */
}

if you default to false then no-one would ever use an empty condition,
because it would be the null loop.

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

#150833

Le 22/03/2020 à 17:16, Scott a écrit :
> On Sun, 22 Mar 2020 15:55:14 +0100, felix@palmen-it.de (Felix Palmen)
> wrote:
> 
>> * Bart <bc@freeuk.com>:
>>> You seem to be forgetting that C HAS a while-loop.
>>
>> You seem to be forgetting that this is actually *the same*¹
>>
>>     statement1;
>>     while (condition) {
>>         [...]
>>         statement2;
>>     }
>>
>> is always *exactly* the same as:
>>
>>     for (statement1; condition; statement2) {
>>         [...]
>>     }
> 
> This is almost always true, except in one circumstance: a while
> statement requires a condition expression, but a for statement does
> not. "for(;;){}" is common shorthand for an infinite loop. There is
> probably a historical reason that for-loops have a default of 'true'
> for an empty loop-condition, but I don't know the details. It must
> have made sense at the time.

I don't know the rationale, but I think all this is a lot of noise for 
not much.

As I see it, the for construct in C is nothing more (at least initially) 
than syntax sugar coating for the above while construct. It's so common 
that a loop have an initialization part, a condition, and some kind of 
"iteration" part, that the for construct was pretty obvious IMO at the 
time as a nice shortcut.

Any 3 statements of a for loop is optional, not just the condition.
That makes it more flexible. Whereas you may question for loops without 
conditions (except for infinite loops), for loops without initilizer can 
be more common, so I see this as just consistency across all 3 statements.

One thing that's really different between for and while, beginning with 
C99, is that local declarations are allowed in the initalizer statement, 
making them strictly local to the loop, something you just can't do with 
a 'while' AFAIK. Such as: 'for (int i = 0; ...)'. Impossible with a 
while. That would be something like:

int i = 0;
while (...)
...

making 'i' visible from the while down to the end of the block 
containing the declaration.

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

#150835

On Wed, 2020-03-25, Guillaume wrote:
...
> I think all this is a lot of noise for not much.

That's my single lasting impression from this whole thread ...

/Jorgen

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

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

#150731

felix@palmen-it.de (Felix Palmen) writes:

> * Bart <bc@freeuk.com>:
>> You seem to be forgetting that C HAS a while-loop.
>
> You seem to be forgetting that this is actually *the same*¹
>
>     statement1;
>     while (condition) {
>         [...]
>         statement2;
>     }
>
> is always *exactly* the same as:
>
>     for (statement1; condition; statement2) {
>         [...]
>     }
>
> *If* "statement1" initializes the control state of the loop and
> "statement2" advances it, writing this as a while-loop is just
> braindead.
>
> ¹ except when "statement1" is a definition with initialization, in that
> case, only a for-loop can limit the scope of some variable
> appropriately.

And they are not the same when continue is used in the loop.  Or when
statement1 or statement2 are actual statements are not just expression
statements.  In fact it would be better not to talk about statement[12]
at all but

  exp1;
  while (exp2) {
      ...
      exp3;
  }

being similar to

  for (exp1; exp2; exp3) {
      ...
  }

and then explain the form

  for (declaration exp2; exp3) {
  }

separately.

-- 
Ben.

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

#150739

On 3/22/20 10:55 AM, Felix Palmen wrote:
...
>     statement1;
>     while (condition) {
>         [...]
>         statement2;
>     }
> 
> is always *exactly* the same as:
> 
>     for (statement1; condition; statement2) {
>         [...]
>     }

<pedantic> That's not quite true: if [...] contains a
continue-statement, the for-statement executes statement2; the
while-statement does not.
</pedantic>

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

#150736

On Sunday, March 22, 2020 at 10:17:30 AM UTC-4, Bart wrote:
> On 22/03/2020 12:47, James Kuyper wrote:
> > On Sunday, March 22, 2020 at 8:23:33 AM UTC-4, Bart wrote:
> 
> >> Most C coders here would still see that as for-loop.
> > 
> > All C coders see it as a for-loop. You have very strong preferences for
> > a language significantly different than C,
> 
> You seem to be forgetting that C HAS a while-loop.

What makes you think that? I provided a C while-loop in the very message
you were responding to. If I had forgotten about their existence, I
would have objected to your while loop on the mistaken grounds that it
was a syntax violation.

> I'm curious now as to under what circumstances anybody here would ever 
> actually use it.

You should know the answer to that; it's been provided many times in
previous discussions you've participated in. Different people have
different opinions on the matter. My own personal criterion is that I
use a for-loop if I have expressions that play a key role in loop
control that can be put into at least two of the first three user-
defined parts of a for-statement. The advantage of the for-loop is that
it packages together all the different parts of the loop control. If
there is only one such part, there's nothing to bring together, in which
case I favor a while- loop.

> >> I see it as just a while loop:
> >>
> >>       count = 0;
> >>       ent = master;
> >>
> >>       while (ent) {
> >>           ++count;
> >>           ent = ent->chain;
> >>       }
> > 
> > And in precisely the same sense,
> >      for(int i=0; i<n; i++)
> >         array[i] = i;
> > 
> > is just a while loop:
> > 
> >      i = 0;
> >      while(i < n){
> >          array[i] = i;
> >          i++;
> >      }
> 
> You could do that. But languages that have 'while' AND 'for', would have 
> introduced 'for' to streamline some common patterns, such as iterating 
> over the inclusive range 0 to N-1.

Exactly - and C enables a much wider range of common patterns than you
approve of. You should really stop using it and switch to a language
that you approve of more. But you can't do that, because no such
language is popular with a sufficiently large number of people to be as
widely available as C. What a dilemma!

> Funnily enough, turning this 'while' into its 'for' version, after 
> making adjustments such as using {} for the loop body, declaring 'i' in 
> the while loop, and ignoring extraneous white-space, only saves about 
> two characters, which can be accounted for by the fact that 'while' is 
> two letters longer than 'for'.

No one has ever suggested that reduced typing was the primary benefit of
a for-loop.

> That suggests to me even less reason for choosing for over while, so the 
> only reason I can see for 'for' being so popular for ANY kind of loop, 
> is that people /like/ writing unreadable and confusing for-headers 
> instead of proper code.

No, it's because we prefer easily readable for-loops over more confusing
equivalent while-loops. Putting the expressions that play the biggest
role in controlling how the loop executes together in one place makes it
easier to understand how the loop is controlled.

In particular, the biggest benefit comes from the piece of the for loop
that you despise the most: the third part of the header. When writing
the corresponding while-loop, that expression would be separated from
the rest of the loop controls by the entire body of the loop, making it
correspondingly harder to connect with the other loop-control
expressions. In fact, one of the most common mistakes, particularly
among newbies, it to accidentally leave out that part when writing a
while-loop. It's much easier to remember to include that part when
writing a for-loop. Of course, you despise it because it's positioned
before the body of the loop, but executed after the body of the loop.
In other words, what makes you despise that feature is directly related
to what users of C for-loops like most about it.

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

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

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

csiph-web