Sujet : Re: do { quit; } else { }
De : david.brown (at) *nospam* hesbynett.no (David Brown)
Groupes : comp.lang.cDate : 12. Apr 2025, 14:52:01
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vtdr61$kstq$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 25
User-Agent : Mozilla Thunderbird
On 12/04/2025 15:21, Richard Heathfield wrote:
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.
But... but... but...!!!
Oh, wait - it does.
...Finally!
typedef int (*FIntInt)(int);
>
FIntInt funcs[10];
Just one tiny point, though. I've never been a fan of hiding pointers behind typedefs. I would much prefer:
typedef int FIntInt(int);
FIntInt *funcs[10];
Better to have those *s out in the open, where we can keep an eye on them.
C is a flexible language, and also caters for those that have heretical opinions. I have no use of a function type in a language that does not treat functions as first class objects - you cannot pass a function as a parameter, return one from a function, or even have a function object. You always deal with pointers to functions. Thus IMHO the pointer should be part of the typedef since you always need it.
(I am not going to say which of us is the heretic here!)
do { quit; } else { }
Re: do { quit; } else { }