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