Re: "A diagram of C23 basic types"

From	Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups	comp.lang.c
Subject	Re: "A diagram of C23 basic types"
Date	2025-04-14 01:46 -0700
Organization	A noiseless patient Spider
Message-ID	<86ecxv9lkx.fsf@linuxsc.com> (permalink)
References	(9 earlier) <vslilm$8mfb$1@dont-email.me> <vsm05b$k0b7$1@dont-email.me> <85y0whjdw3.fsf@nosuchdomain.example.com> <vsmlc4$1c39t$1@dont-email.me> <85ldshjb72.fsf@nosuchdomain.example.com>

Show all headers | View raw

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

[considering ways of importing all headers defined as part
 of the standard library]

> My point is that, as far as I'm aware, nobody has implemented
> "implicitly include all the standard headers", either as a compiler
> option or as a wrapper script.  I'm sure somebody has (I could do
> it in a few minutes), but it's just not something that programmers
> appear to want.
>
> Of course part of the motivation for *not* wanting this is that
> it results in non-portable code, and if it were standardized that
> wouldn't be an issue.
>
> And if it were standardized, <assert.h> would raise some issues,
> since NDEBUG needs to be defined or not defined before including it.

Not really a problem, since if a different choice for NDEBUG were
desired then it could be #define'd or #undef'ed, as appropriate,
followed by another #include <assert.h>.

That said, it's hard to imagine many people wanting such a thing.
It's a very rare translation unit that needs or even wants access
to symbols defined in every header in the standard library.  And
it flies in the face of the common practice of #include'ing only
those headers that are actually needed in each translation unit.

Back to comp.lang.c | Previous | Next | Find similar

Thread

Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-14 01:46 -0700

csiph-web