From: Keith.S.Thompson+u@gmail.com
bart writes:
> On 23/10/2025 02:19, Thiago Adams wrote:
>> Em 22/10/2025 18:39, Keith Thompson escreveu:
>>> This is cross-posted to comp.lang.c and comp.lang.c++.
>>> Consider redirecting followups as appropriate.
>>>
>>> cdecl, along with c++decl, is a tool that translates C or C++
>>> declaration syntax into English, and vice versa. For example :
>>>
>>> $ cdecl
>>> Type `help' or `?' for help
>>> cdecl> explain const char *foo[42]
>>> declare foo as array 42 of pointer to const char
>>> cdecl> declare bar as pointer to function (void) returning int
>>> int (*bar)(void )
>>>
>>> It's also available via the web site .
>> This one does not work:
>> void (*f(int i))(void)
>
> KT said the newer version is only available by building from source
> code, which must be done under some Linux-compatible system.
As far as I know, it should build on just about any Unix-like system,
not just ones that happen to use the Linux kernel. Perhaps that's what
you mean by "Linux-compatible"? If so, I suggest "Unix-like" would be
clearer. (I'm building it under Cygwin as I write this.)
> I've had a look: it comprises 32Kloc of configure script, and 68Kloc
> of C sources, so 100Kloc just to decode declarations! (A bit longer
> than the 2-page version in K&R2.)
Yes, and neither you nor I had to write any of it. I cloned the repo,
ran one command (my wrapper script for builds like this), and it works.
I wonder how many lines of code are required for the specification of
the x86_64 CPU in the computer I'm using to write this. But really,
it doesn't matter to me, since that work has been done, and all I
have to do is use it.
The configure script is automatically generated (I mentioned the
"bootstrap" script that generates it if you build from the git repo).
I suppose building it under Windows (without some Unix-like layer
like MinGW or Cygwin) would be more difficult. That's true of
a lot of tools that are primarily used on Unix-like systems.
It's likely that the author of the code doesn't care about Windows.
I agree that it can be a problem that a lot of code developed for
Unix-like systems is difficult to build on Windows. For a lot
of users, an emulation layer like Cygwin, MinGW, or WSL is a good
enough solution. If it isn't for you, perhaps you could help solve
the problem. Perhaps the GNU autotools could be updated with better
Windows support. I wouldn't know how to do that; perhaps you would.
"Don't use autotools" is not a good solution, since there are so
many software packages that depend on it, often maintained by people
who don't care about Windows.
> (There's a further 30Kloc of what looks like C library code. So is
> this a complete C compiler, or does it still only do declarations?)
I haven't looked at the source code (I haven't needed to), but the man
page indicates that this version of cdecl recognizes a number of types
defined in the standard library, such as FILE, clock_t, and
std::partial_ordering (remember that it includes C++ support).
I don't know whether all this could be done in fewer lines of code, and
frankly I don't much care. The tool works and is useful, and I didn't
have to write it.
Have you tried using it? I'm sure you have some system where you could
build it.
> Regarding your example, my old C compiler (which is a fraction the
> size of this new Cdecl) 'explains' it as:
>
> 'ref proc(int)ref proc()void'
>
> (Not quite English, more Algol68-ish.)
Can I run your old C compiler on my Ubuntu system?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
