Sujet : Re: Suggested method for returning a string from a C program?
De : bc (at) *nospam* freeuk.com (bart)
Groupes : comp.lang.cDate : 21. Mar 2025, 12:53:17
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vrjjvb$1esjh$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
User-Agent : Mozilla Thunderbird
On 21/03/2025 01:47, Keith Thompson wrote:
bart <bc@freeuk.com> writes:
You're complaining about how much work it is. All that work
has been done for you by the implementers. Decades ago.
We are talking about defining types like 'int32' on top of 'char short int long', yes? Then how difficult could it possibly be?
I just
did a quick test comparing complation times for an empty program
with no #include directives and an empty program with #include
directives for <stdint.h> and <inttypes.h>. The difference was
about 3 milliseconds. I quite literally could not care care less.
I'm sorry but that's a really poor attitude, with bad consequences. You're saying it doesn't matter how complex a header or set of headers is, even when out of proportion to the task.
But this is why we end up with such complicated headers.
Take the GTK2 library with hundreds of header files. The compiler has to process all that, for each module that includes GTK (specifically, 350Kloc across 550 unique headers via ~1000 #includes).
That's a lot of work, and leads to poor solutions like PCH, which are specific to certain compilers.
But I happen to know that all those declarations could be flattened into a single 25Kloc header file (I don't mean just using -E; all #defines are retained for example).
While the 75 headers and 50K lines of SDL2 reduce to one 3Kloc header. Much easier to manage one interface file! And quicker to compile.
So, why isn't that routinely done by the purveyors of libraries? (Or is everyone who downloads the GTK /headers/ for example keen to do their own development!)
The user of the ONE library doesn't care about the internal structure of the header files.
I think your response clarifies matters. Nobody cares, even as compilers grind to a halt under all preprocessing.
Doing stuff the C way requires LOTs of lines of code. Look at all
those MIN/MAX macros, the PRINT/SCAN macros; there's hundreds of them!
So what? I don't have to read those lines of code. All I have to read
is the standard (or some other document) that tells me how to use it.
It is crass. But it also affects the programmer because they have to explicitly include that specific header and then remember the dedicated MIN/MAX macros for the specific type. And they have to /know/ the type.
If the type is opaque, or is an alias, then they won't know the name of the macro. If the typedef is 'T' for example, then what's the macro for its MAX value? Which header will they need?
In a certain language I use, it will be T.max (and there are no headers). I'm not suggesting that C turns into that language, only that somebody acknowledges the downsides of using C's approach, since again nobody cares.