Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Loops (was Re: do { quit; } else { })
Date: Tue, 15 Apr 2025 20:50:45 -0700
Organization: None to speak of
Lines: 38
Message-ID: <87h62o2296.fsf@nosuchdomain.example.com>
References: <vspbjh$8dvd$1@dont-email.me> <vtc7mp$2q5hr$1@dont-email.me>
	<vtcqf6$3j95s$1@dont-email.me> <vtdh4q$b3kt$1@dont-email.me>
	<vtf7fe$1qtpg$1@dont-email.me> <vtgfuf$31ug1$1@dont-email.me>
	<20250413072027.219@kylheku.com> <vtgpce$39229$1@dont-email.me>
	<vti2ki$g23v$1@dont-email.me> <vtin99$vu24$1@dont-email.me>
	<vtiuf0$18au8$1@dont-email.me> <vtj97r$1i3v3$1@dont-email.me>
	<vtl166$36p6b$1@dont-email.me> <vtlcg0$3f46a$2@dont-email.me>
	<20250415053852.166@kylheku.com> <vtm4ae$6d5j$1@dont-email.me>
	<H7yLP.2056536$OrR5.1414451@fx18.iad> <vtmgj8$g81k$1@dont-email.me>
	<vtn55a$17107$1@dont-email.me> <20250415201754.605@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Wed, 16 Apr 2025 05:50:47 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d66e934c2e3cca42eaa548516797f624";
	logging-data="1124468"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18hUdNLQuh+JDWWktZNIyBJ"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:FAaVqrLT5SX8Y2aaFW2lIYecD4s=
	sha1:B/KWoOEo8Ydop3HOz9sezJpuvZU=
Bytes: 2867

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.com
void Void(void) { Void(); } /* The recursive call of the void */