Re: "A diagram of C23 basic types"

BGB <cr88192@gmail.com> writes:

On 4/2/2025 11:06 PM, Tim Rentsch wrote:
>

Kaz Kylheku <643-408-1753@kylheku.com> writes:
>
[some symbols are defined in more than one header]
>

(In my opinion, things would be better if headers were not allowed
to behave as if they include other headers, or provide identifiers
also given in other heards.  Not in ISO C, and not in POSIX.
Every identifier should be declared in exactly one home header,
and no other header should provide that definition.  [...])

>
Not always practical.  A good example is the type size_t.  If a
function takes an argument of type size_t, then the symbol size_t
should be defined, no matter which header the function is being
declared in.  Similarly for NULL for any function that has defined
behavior on some cases of arguments that include NULL.  No doubt
there are other compelling examples.

>
Yes, basically true.
Headers including headers that have needed functionality makes sense.
>
>
>
At the other extreme, say we have a header, lets just call it
"windows.h", which then proceeds to include nearly everything in the
OS "core".  No need to include different headers for the different OS
subsystems, this header has got you covered.
>
But, then one proceeds to "#include" all of the other C files into a
single big translation unit, because it is faster to do everything all
at once than to deal with "windows.h" for each individually (because
even a moderate sized program is still smaller than all the stuff this
header pulls in).
>
>
But, then one has to care about relative order of headers, say:
If you want all this extra stuff, "windows.h" needs to be included
first, as the other headers will define _WIN32_LEAN_AND_MEAN (or
something to this effect) which then causes it to omit all of the
stuff that is less likely to be needed.
>
So, say:
  #include <GL/gl.h>
  #include <windows.h>
>
Will give different results from:
  #include <windows.h>
  #include <GL/gl.h>
>
...

Yes, undisciplined use of #include leads to problems.

The solution is to impose some rules on how header files are
written, so as to avoid the kinds of problems you describe.
That isn't hard, and people have been writing headers in
such a way since well before the first C standard was
written.