Sujet : Re: do { quit; } else { }
De : bc (at) *nospam* freeuk.com (bart)
Groupes : comp.lang.cDate : 12. Apr 2025, 17:52:16
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vte5o1$umr8$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
User-Agent : Mozilla Thunderbird
On 12/04/2025 14:43, David Brown wrote:
On 12/04/2025 03:27, bart wrote:
C type syntax is famous for being difficult and confusing; I think most will agree about that. Even the creators said so.
I disagree with that claim. I think it is probably fair to say that advanced, complicated and multi-layer types are difficult in any programming language.
But a type that is a simple linear chain should be straightforward, and usually is, just not in C. That was illustrated here:
array of 10 pointer to function taking int and returning int
1 2 3 4 5 6
The C correspond to that fantastically complicated type (an array of function references!) is:
int (*A[10])(int);
6 3 1 2 4 5 (Not sure which bit is the '4')
The numbers below show the crazy mixed-up correspondence with the left-to-right original. Using the made-up LTR syntax of a prior post:
[10]* fn(int)int A
1 2 3 4 5 6
The bits correspond EXACTLY.
Now I want a new type which is a pointer to such an array. In that new syntax you just add * on the left:
*[10]* fn(int)int A
In the C, you also need to add *, but where?! It is by no means obvious. In fact it is this (I had to employ Cdecl):
int (*(*A)[10])(int )
I had to add '*' and also '()' in a critical place. I still don't know which of those * is which.
As I've many times, this is completely unfit for purpose. Beyond the simplest examples, this is just gibberish.
With LTR syntax, you can create arbitrarily complex chains, and you will always now exactly what they mean, and which * is which. Modifying them is trivial:
C LTR style
int A[10] [10]int A # array of int
int *A[10] [10]*int A # array of pointer to int
int (*A)[10] *[10]int A # pointer to array of int
int *(*A)[] *[]*[]int A # ptr to array of ptr to int
int *(*A)[], B *[]*[]int A, B
In the last example, A and B are different types in the C column (B is a simple int); in the LTR column, both are exactly the same type, another advantage.
There is just no comparison. LTR style is far superior, more convenient, more readable, easy to write, and less error prone.
To be clear - I think putting a complicated type declaration on a single line makes code harder to read.
As C does it, yes. But the threshold at which it becomes gobbledygook is too low.
A vast number of people have written a vast amount of code in C. Clearly it is /not/ too complicated, or onerous, or slow.
That just means vast numbers have HAD to write complicated, onerous code. What other choice did they have? What alternates to C were possible?
I have said multiple times that if I were to design a new programming language, its syntax would differ significantly from C's.
But it would be a toy unless you could get it adopted by lots of people.
By your standards, even a DSL that you create for use in your professional work would be a toy.