Sujet : Re: Loops (was Re: do { quit; } else { })
De : 643-408-1753 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.lang.cDate : 21. Apr 2025, 23:16:54
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20250421145818.767@kylheku.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
User-Agent : slrn/pre1.0.4-9 (Linux)
On 2025-04-21, bart <
bc@freeuk.com> wrote:
I don't now think think there is any argument that will make any
difference. People here genuinely think that writing:
>
for (ch = 0; ch <= 255; ++ch)
>
is far superior to this 'primitive' version:
>
do ch = 0, 255
Obviously, the former is more primitive, because the second can
be made out of the first with a preprocessor, whereas the converse
is not true. If A can be made out of B, but B not out of A,
B is more primitive.
The former is undeniably more verbose for the uses provided by the
second.
It is also much more flexible.
Thanks to the macro preprocessor, it can almost express the second form,
just with more punctuation:
for_range (ch, 0, 255)
If a built-in "do" range loop existed in C, it would likely have
the parentheses.
No amount of discussion or arguments will make them change their minds.
Mostly, you are projecting onto people opinions they don't actually
have.
(BTW I had to fix two typos in the C, as in the first version I
initially used 'ch, c and c'!)
>
Apparently, the C form is superior because that construct can also be
used to conveniently express link-list traversal, and a lot more.
It has superior flexibility. Flexible is not a synonym for superior;
flexibility doesn't make something unequivocally superior, unless we can
hold "all else equal". We can almost never do that. Here, the flexible
thing is more verbose, and there are challenges implementing a simple
range iteration that can go (for instance) all the way to INT_MAX,
whereas the less primitive loop can get that right and completely hide
it from the programmer.
Even the idea of having *two* kinds of loop, one as it works now, and
one more streamlined, was not acceptable: too much 'overloading' of the
language.
You're also not a fan of unbridled language extension, based on your
past opinions about, oh, C++ and whatnot.
Your primary reaction to some new idea is to reject it as complex
fluff that you'd rather not undertand.
How brushed up are you in using C17 or C23?
You've also expressed oppositions to extending C, because
development of C makes it a moving target for your projects.
Of course people are going to push back on the idea of making new
statements, if they can be decently obtained or simulated using
preprocessing.
Would you support an "unless" statement being added to C, given
that we can just:
#define unless(x) if(!(x))
Or, unless which does not take else:
#define unless(x) if (x) { } else
Adding a new statement to C is a big deal, compared to someone
adding a macro to their code.
Literally the first question about any proposal for a new language
feature is going to be: can obtain that, or substantially obtain it
using existing features
-- TXR Programming Language: http://nongnu.org/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca