home bbs files messages ]

Just a sample of the Echomail archive

COMPLANC:

<< oldest | < older | list | newer > | newest >> ]

 Message 241,608 of 243,097 
 Chris M. Thomasson to Janis Papanagnou 
 Re: New and improved version of cdecl 
 27 Oct 25 23:47:49 
 
From: chris.m.thomasson.1@gmail.com

On 10/27/2025 8:10 PM, Janis Papanagnou wrote:
> On 27.10.2025 18:44, bart wrote:
>> On 27/10/2025 16:35, David Brown wrote:
>>> On 27/10/2025 12:22, bart wrote:
>>
>>
>> /My syntax/ (as in my proposal) is bizarre,
>
> What was your proposal? - Anyway, it shouldn't be "bizarre"; it's
> under your design-control!
>
>> but actual C type syntax isn't?!
>
> There were reasons for that choice. And the authors have explained
> them. - This doesn't make their choice any better, though, IMO.
>
>>
>> The latter is possibly the worst-designed feature of any programming
>> language ever, certainly of any mainstream language. This is the syntax
>> for a pointer to an unbounded array of function pointers that return a
>> pointer to int:
>>
>>      int *(*(*)[])()
>>
>> This, is not bizarre?!
>
> You need to know the concept behind it. IOW, learn the language and
> you will get used to it. (As with other features or "monstrosities".)
>
>> Even somebody reading has to figure out which *
>> corresponds to which 'pointer to', and where the name might go if using
>> it to declare a variable.
>>
>> In the LTR syntax I suggested, it would be:
>>
>>     ref[]ref func()ref int
>>
>> The variable name goes on the right. For declaring three such variables,
>> it would be:
>>
>>     ref[]ref func()ref int a, b, c
>>
>> Meanwhile, in C as it is, it would need to be something like this:
>>
>>      int *(*(*a)[])(), *(*(*b)[])(), *(*(*c)[])()
>>
>> Or you have to use a workaround and create a named alias for the type
>> (what would you call it?):
>>
>>      typedef int *(*(*T)[])();
>>
>>      T a, b, c;
>>
>> It's a fucking joke.
>
> Actually, this is a way to (somewhat) control the declaration "mess"
> so that it doesn't propagate into the rest of the source code and
> muddy each occurrence. It's also a good design principle (also when
> programming in other language) to use names for [complex] types.
>
> I take that option 'typedef' as a sensible solution of this specific
> problem with C's underlying declaration decisions.
>
>> And yes, I needed to use a tool to get that first
>> 'int *(*(*)[])()', otherwise I can spend forever in a trial and error
>> process of figuring where all those brackets and asterisks go.
>>
>> THIS IS WHY such tools are necessary, because the language syntax as it
>> is is not fit for purpose.
>
> I never used 'cdecl' (as far as I recall). (I recall I was thinking
> sometimes that such a tool could be useful.) Myself it was sufficient
> to use a 'typedef' for complex cases. Constructing such expressions
> is often easier than reading them.
>
>> [...]
>>
>>> Yes, my ideal would be different from the output of cdecl.  No, the
>>> author is not doing something "wrong".  I live in a world where
>>> programming languages are used by more than one person, and those
>>> people can have different opinions.
>>
>> Find me one person who doesn't think that syntax like  int *(*(*)[])()
>> is a complete joke.
>
> Maybe the authors (and all the enthusiastic adherents) of "C"?

Does extern "C" tend to use cdecl?

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)

<< oldest | < older | list | newer > | newest >> ]


(c) 1994,  bbs@darkrealms.ca