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: Sun, 20 Apr 2025 15:36:23 -0700
Organization: None to speak of
Lines: 166
Message-ID: <87ecxmv4t4.fsf@nosuchdomain.example.com>
References: <vspbjh$8dvd$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> <vtnekn$1fogv$1@dont-email.me>
	<vto2mb$20c4n$1@dont-email.me> <vtu4i5$3hteg$1@dont-email.me>
	<vtujko$3uida$1@dont-email.me> <vtvfop$rf2p$1@dont-email.me>
	<vtvto2$15otp$1@dont-email.me> <vu01k7$1bfv2$1@dont-email.me>
	<vu0720$1dva7$1@dont-email.me> <vu2hmg$3jn88$1@dont-email.me>
	<vu2mkc$3noft$1@dont-email.me> <vu38da$735n$1@dont-email.me>
	<vu3j7s$g755$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Mon, 21 Apr 2025 00:36:23 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9df2d817d671536e75ba887619a4c13a";
	logging-data="730752"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+q3AVYY+SaTfNNnMYWTnvX"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:eTjXDKgVnAhy31NF0GVidyAKcB8=
	sha1:SZasSDvaSSJv2dCz72b0JufOJwc=
Bytes: 7789

bart <bc@freeuk.com> writes:
> On 20/04/2025 17:46, Janis Papanagnou wrote:
>> On 20.04.2025 13:43, bart wrote:
>>> On 20/04/2025 11:18, Janis Papanagnou wrote:
>>>> On 19.04.2025 15:05, bart wrote:
>>>
>>> But overloading in the form of 30-40 integer types to represent the 8
>>> types i8-i64 and u8-u64, plus the 16 different combinations of writing
>>> 'unsigned long long int', and so on, is fine. As are the dozens
>>> (hundreds?) of macros in stdint.h/inttypes.h.
>> I haven't said this "is fine". It wasn't at all the topic here.
>
> Sorry, I forgot the rules. Only YOU are allowed to call adding one
> extra loop type 'overloading' of the language. But *I* am not allowed
> to call the plethora of integer types and support macros 'overloading'
> of the same language.
>
>
>>> Show me a for-loop that cannot be expressed with existing features. Many
>>> are likely to be clearer!
>> (There have been sufficient examples posted.)
>
> In C? I don't recall any examples in C that could be written without 'for'.
>
>> It makes not much sense to spread them across a multi-line block
>> of statements. - If you haven't ever experienced that, and still
>> cannot see and understand that if explained to you, then I can't
>> help you.[*]
>
> Here's the example you snipped:
>
>     for(p=sqliteHashFirst(&pSchema->trigHash); p; p=sqliteHashNext(p)){
>         sqlite3DeleteTrigger(db, (Trigger*)sqliteHashData(p));
>     }
>
> In my opinion, that for-header is too complex. You can barely make out
> the condition (that lonely 'p' which you have to hunt for).

I see your point.  I don't object to the way it's written, and I
presume it follows the coding style of the rest of the sqlite code.
I can see how the density might throw somebody off.  But I presume
it's quite clear to the people to whom it needs to be clear, the
sqlite maintainers.

I might write it like this:

    for ( p = sqliteHashFirst(&pSchema->trigHash);
          p != NULL;
          p = sqliteHashNext(p) )
    {
        sqlite3DeleteTrigger(db, (Trigger*)sqliteHashData(p));
    }

I have certain preferences (spaces around most operators, explicit
comparison to NULL, willingness to split long lines) that other C
programmers may or may not share.

But the original form was clear enough to me.

[...]

> So what about this then (another example you snipped):
>
>  for(p=sqliteHashFirst(&pSchema->trigHash); p;
>  sqlite3DeleteTrigger(db, (Trigger*)sqliteHashData(p)),
> p=sqliteHashNext(p));
>
> It keeps it even more together, which you seem to like.

That's something you invented.  I find it ugly, and I presume you'd
agree.  The fact that you think that someone else would prefer it
indicates that you don't understand how other people think.

[...]
> I think it is YOU whose brain is so bound to having just the ONE kind
> of loop to do half a dozen different jobs, none of them well.

That wasn't addressed to me, but when I'm programming in C I'm using
a language that has three kinds of loop (for, while, do/while),
all of which work just fine for my purposes.  When I'm programming
in other languages, I use the constructs they provide.

[...]

> This is an example which I started off trying to simplify:
>
>  for (monthIdx = 0; monthIdx < 12 && yearDay >=
>  yearDays[leapYear][monthIdx]; monthIdx++) ;
>
> I simply can't see it. So the first step is to turn it into a while loop:
>
>    monthIdx = 0;
>    while (monthIdx < 12 && yearDay >= yearDays[leapYear][monthIdx])
>       monthIdx++;
>
> Now at least I can see the condition! I'm sorry, but if prefer the
> original, then I don't want to have to debug or maintain your code.

If I need to split a long line, I try to do so between high-level
subparts.

Did it not occur to you to rewrite it like this?

    for (monthIdx = 0;
         monthIdx < 12 && yearDay >= yearDays[leapYear][monthIdx];
         monthIdx++);

Each of the three clauses gets one line.  That's allowed, you know.

> Here I would go further and use a short loop index:
>
>    m = 0;
>    while (m < 12 && yearDay >= yearDays[leapYear][m]) ++m;
>
> This one is a simple iteration:
>
>     for (character = 0; character <= 255; character++) {
>
> At least I can see it. However this is simply crying out to be written as:
>
>    for (ch in 0..255)
>
> You don't get that? You'd rather keep it long-winded because you can
> do linked-lists too?!

You conflate two separate issues.

One is whether C's constructs are well designed.  That's something
I don't spend a lot of time thinking about (though probably more
than most programmers do).

The other is how C's constructs are actually defined.  Understanding
that is critical to being able to program in the language.
Your personal taste, or mine, is entirely irrelevant to that.

I'd rather not write `for (ch in 0..255)` because it's a syntax error.

You have the luxury of using your own language.  If you don't like
something in the language, you can change it.  Hardly anyone else is in
that position.  That's why the rest of us, for the most part, calmly
accept the way a language is defined, and worth within it.

> I just don't get the love. Or maybe, nobody here (perhaps apart from
> Keith) is willing to admit that there's anything wrong with 'for'.

It's (mostly) not "love".  Mostly, it's programmers accepting the
way a language is defined, like or not, for the sake of getting
work done.  When talking to you, we're responding to unwarranted
attacks on a language most of us know reasonably well, and many of
us actually like.

Literally nobody thinks C is perfect.

> I said I tried one like C's, and it was never used. There is enough
> flexibility in the rest to deal with anything that comes up.

It was never used by whom?

If you don't like C-style for loop, they absolutely should not
exist in a language for which you are, if I understand correctly,
the sole implementer and the sole user.  Generalizing from that
experience is, I suggest, silly.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */