Re: do { quit; } else { }

On 12/04/2025 13:39, David Brown wrote:

On 12/04/2025 01:13, bart wrote:

On 11/04/2025 22:36, Keith Thompson wrote:

bart <bc@freeuk.com> writes:
[...]

Rubbish. Everyone finds C declaration syntax a nightmare.

>
Rubbish.  I find C declaration syntax annoying, not a "nightmare".
>

>
Annoying would be having to get letter case or punctuation just right.
>
But C typepecs can go far beyond it. I can just about do arrays of pointers, or pointers to arrays. Anything more complicated is pretty much trial and error.
>
In an example in my post which I then deleted (DB will just ignore examples), I wanted to create an array of 10 pointers to functions that take an int and return an int.

 If only C had a way to make that simple and clear.  Oh, wait - it does.
      typedef int (*FIntInt)(int);

Um, not really! You still need to /analyse/ this to see what exactly this is. You don't know it might be to do with functions until you hit the /second/ opening parenthesis. Unless somebody writes:
 >      typedef int ((*FIntInt))(int);
then it's the /third/ parenthesis!

     FIntInt funcs[10];

This is a comment I posted yesterday:
"If you need a program to help you read C programs, that suggests a serious flaw in C."  (https://news.ycombinator.com/item?id=42564861)
The same applies to having to use workarounds (and needing to invent spurious user types) to write not very complicated typespecs.

If a C programmer - such as yourself - is foolish enough to reject parts of the language designed to make coding simpler, safer, clearer and more portable, then I can see how your self-imposed restrictions make your coding harder.  But the fault lies in the poor use of the language, not the language.

No, the fault likes in the language for having such appalling syntax in the first place.
My last post touched on this, but it is the idea that a composite type requires 'modifiers' that wrap around each name that is declared in a list:
     T *A[10], (*B)[10], ***C, (*D)(int,int);
So the type for D involves T on the far left; '*' on its immediate left; '(int,int)' on its right; plus those parentheses are needed to alter precedence (in a type-spec!).
This is effing crazy, and you know it. It also gives rise to problematic code like this:
    T** A, B, C;
 >designed to make coding simpler, safer, clearer and more
Was typedef really designed to mitigate the problems of its type syntax? I doubt very much: Let's create this really stupid syntax, and let's then add X, Y and Z so that you don't need to use that stupid syntax.
To complete your example:
    typedef int ((*FIntInt))(int);
    typedef FIntInt AFintInt[10];
    AFIntInt Table1, Table2, Table3;
Two lots of typedefs, and two extra user-identifiers, when it could have been done like this, using a made-up LTR syntax:
    [10]*fn(int,int)int Table1, Table2, Table3;
Everything is in one place without having to hunt down typedefs. No unnecessary user types. All three variables are guaranteed to have compatible types.
And you can read off the actual type by simply scanning left-to-right, without using any tools or algorithms.
I haven't mentioned my language (and this uses a different syntax), so you can't dismiss this by saying it's a toy! You know this is, and would have been, a far better scheme.