Sujet : Re: Loops (was Re: do { quit; } else { })
De : Keith.S.Thompson+u (at) *nospam* gmail.com (Keith Thompson)
Groupes : comp.lang.cDate : 16. Apr 2025, 04:50:45
Autres entêtes
Organisation : None to speak of
Message-ID : <87h62o2296.fsf@nosuchdomain.example.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
User-Agent : Gnus/5.13 (Gnus v5.13)
Kaz Kylheku <
643-408-1753@kylheku.com> writes:
On 2025-04-16, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
[...]
The key to using the for() statement is to make sure the three
expressions are related appropriately.
>
The observation is valid that the three expressions often fall into a
pattern by which they can be condensed.
>
for (var = from; var < to; var++)
>
can be expressed by a construct which mentions var ony once,
and omits the operators.
>
You can obtain this with the preprocessor and be reasonably happy.
Sure, you *can*, but I wouldn't.
For me the raw C-style for loop is clear enough.
I could write a macro like:
#define ITERATE(var, from, to) for ((var) = (from); (var) < (to); (var)++)
but then anyone reading the code has to understand both how C-style
for loops work and how the ITERATE macro works. Does the expansion
use < or <=? What happens if "to" is INT_MAX? Did the author of
the macro get everything right?
Now if someone else finds that such a macro makes things easier for
them, that's fine. But often, *in my opinion*, such macros make code
harder to read for someone who knows C well.
[...]
-- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.comvoid Void(void) { Void(); } /* The recursive call of the void */