Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Comma operator in for() statements Date: Mon, 23 Mar 2020 16:27:36 -0700 Organization: None to speak of Lines: 61 Message-ID: <87wo7aps7r.fsf@nosuchdomain.example.com> References: <0fc029c2-7036-4ca9-86af-15913f874a08@googlegroups.com> <4fbkkg-2kr1.ln1@mail.home.palmen-it.de> <4fa819d5-bc63-4c81-bc3f-b328dfc0008a@googlegroups.com> <1a9cdf79-5489-43d0-a050-888012804ca2@googlegroups.com> <87zhc72f0u.fsf@bsb.me.uk> <6ed3fe7f-aa6e-41b7-9753-285b616c2cf4@googlegroups.com> <87eetirfyb.fsf@nosuchdomain.example.com> <871rpirdt3.fsf@nosuchdomain.example.com> <5788dcca-ca28-4fb4-b454-89436c601d0c@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="cddcfdf96fa244ceeb789ef1142863d8"; logging-data="13784"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18OcsWatPijif35yMGLvo2C" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cancel-Lock: sha1:wz3SbrzX+EgsiP6bnKgbwEa+8v4= sha1:nt433PO7LYmkh8Xl6G+ici46SnA= Xref: csiph.com comp.lang.c:150787 Malcolm McLean writes: > On Monday, 23 March 2020 20:56:01 UTC, Keith Thompson wrote: >> Malcolm McLean 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 */