On 22/04/2025 02:12, bart wrote:
On 21/04/2025 23:16, Kaz Kylheku wrote:
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.
It is very rare that rants, exaggerations, and highly subjective opinions change anyone's opinions. You have presented no evidence or rational argument for your own viewpoint - merely an opinion that you don't like C's for-loop syntax.
It is not news to any C programmer that C's for-loop syntax is different to that of a number of other languages - and that like a lot of C syntax, its flexibility has its advantages and disadvantages.
But if you want to show that C's for-loop syntax is /bad/, not just say that you don't like it (which is a subjective opinion, and as such you are free to hold whatever views you like), you have to demonstrate that there are clear and significant issues with it. You have to show that it is a problem for C programmers. It is not enough to show that it takes more keystrokes or tokens than some alternatives, or that there are people other than yourself who dislike it. It is not enough to show that some C programmers make macros for their own convenience, or that most for-loops in C are simple counters that have a shorter syntax in many languages.
If you want to demonstrate that C's for-loop syntax is objectively a bad design, you need to show that it is a source of real-world errors or real-world lack of productivity. That means you need to point to errors in the way for-loops are written being behind a statistically significant fraction of CVE entries, or research papers or surveys showing that it is something people regularly get wrong in C programming. Or you can point to studies showing that using a language similar to C, but with a different loop syntax, is measurably more productive. (Ironically for you, the nearest here would be the C++ syntax for for-loops over containers.)
I don't believe you will be able to provide any such reference. If you could, then I am sure at least some people here would accept that C's for-loops are a dangerous and therefore poor choice of syntax - though personal preference is still personal preference.
Until then, your posts are as convincing as someone claiming strawberry is a terrible flavour for ice cream.
Had you picked another aspect of C, such as the ease of writing code with buffer overflows, you could provide objective proof that the C way of handling arrays and strings is a lot more dangerous than modern C++, Python, or even old BASIC in that respect.
>
Mostly, you are projecting onto people opinions they don't actually
have.
Read the thread. Nobody has changed their opinion on C for-loops, or agreed with its various problems, or thought that a streamlined loop would be a welcome.
I don't see anyone disagreeing with you about the claim that no one has changed their opinion as a result of your rants. But I regularly see you making claims about what other people have said or meant, without justification.
(Only Keith cautiously welcome the idea of such a feature, while MS said he would vote against it, and JP said they would have proposed it on April 1st.)
I don't recall reading Keith saying any such thing. He said he would be willing to nit-pick a proposal for a new "for-loop" syntax - not that he would welcome it. Perhaps he just thinks he would enjoy nit-picking such a paper. As for using a feature if it were added to C, I know I probably would do so in my own code - that does not imply that I think such a feature is needed, or that I have any trouble using C's current syntax for simple loops. (I find C++'s alternative for-loop syntax nicer for iterating over containers, but that is not as easily translatable into C.)
>
You're also not a fan of unbridled language extension, based on your
past opinions about, oh, C++ and whatnot.
I don't agree with language-building features. You just end up with a monstrosity like C++.
C++ has, as noted above, an alternative for-loop syntax that is a lot simpler for some uses - "for (auto x : vec) { ... }" iterates over a vector, C++ array, or other container.
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?
C23 is nothing particularly interesting. A few features I wont't be able to rely on until I'm dead.
You've also expressed oppositions to extending C, because
development of C makes it a moving target for your projects.
As I said, development of is not that interesting. Basically sticking plaster fixes.
> 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.
You can't /just/ add such a macro. To be useful, it has to be standardised. And then, you'd probably need #include <stdunless.h> to use it.
You can, if fact, simply add such a macro if that is something you want to do. If you find it useful, use it. That is part of the beauty of /not/ putting this kind of thing into the core language - it is completely optional, and people can make their own choices.
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
I think C's macros are the main thing that have hindered its development.
I think you are wrong.
And I think you haven't the slightest shred of evidence to support your opinion. I, on the other hand, have at least some justification - the C standards committee have written that they intentionally change the C language slowly, valuing stability of the language and compatibility with existing code over new features and language changes.
Why add a new core feature, when some tacky, half-assed macro can be used? Or, sometimes, a typedef.
A good guideline for language design is that you /never/ change core features if you can implement the feature you want as part of the language library. For established languages, the main motivation for changing the language is to provide better support for features in the standard library - to make them more efficient, or significantly easier to use.
You live in a very different world from serious, mainstream languages, libraries and programming. In your world, it's as easy to add a function to the core language as it is to add it to the user application code, so you have a very different balance. Other language designers, language implementers, and language users do not work that way.
At one time, every other app I looked at defined its own ARRAYLEN macro, or MIN/MAX, or STREQ.
I guess I am the exception - I've never needed any of these. But for your information, C23 has a _Lengthof operator as well as features making it easier to make a better min or max macro, and C++ has all of these features defined in its standard library. I assume, however, that you feel C++ is evil for implementing min and max as library template functions that are easy to use and do not conflict with programmer's choices to use those same identifiers themselves. You would rather fill the core language with an increasingly large number of junk functions that cause more and more compatibility issues with user code.
There is no need to add a formal lengthof() operator when every user can create their own variation of ARRAYLEN in a few seconds.
Correct. And most people don't create their own ARRAYLEN - why do so when you can write the same expression clearly and simply in a few seconds when you need it? And why even do that, when you almost always know the length of the array you are dealing with in the first place?
Result: most people still end up writing sizeof(myarray)/sizeof(myarray[0]).
I think most people write "n", or "buffer_size", or whatever expression they already have for the array in question.
In the meantime, I'm been able to write myarray.len for 43 years, and also:
print a, b # who cares about format codes
Convenient print formatting is one area where I agree C is poor.
As for MIN/MAX, I routinely use:
max(a, b)
max(x, y) # overloaded per type
a max:=b # augmented assignment
a.max # maximum value of a's type
T.max # maximum value of type T
I personally don't see "max" or "min" operations coming up very often in my code. And when I do, it is often not by itself :
if (x[i] > max) {
max = x[i];
max_index = i;
show_new_max_value(max);
}
A built-in "max" function or operator would mean I needed a different identifier, and it would not be of any use in such code anyway.
It is, at most, a trivial thing.
Oh, and I already have Unless:
unless a then b end
return 0 unless cond
It is not a macro.
It is not good either - IMHO. You end up with time flowing forwards in some bits of your code, and backwards in other bits, which makes it significantly harder to follow.
do { quit; } else { }
Re: do { quit; } else { }