Re: [9fans] Include guards and multiple includes

[Charles Forsyth <forsyth@terzarima.net>]

>>A better argument comes from a recent post on comp.lang.c:

perhaps another approach is constructive, in the sense of considering
what one's trying to achieve with the constructions, and using constructions
to suit, rather than a negative argument (nested #includes are slow to compile,
or there might be unused ones).

for instance, the plan 9 scheme might be said to result from observing that
the unit of shared modularity (in practice) in C code is `the library'.
so: there's one #include file per library.  one library might depend on another,
but not mutually (so #includes can be simply ordered, reflecting that dependency).
you need to know in your own programs which libraries are in use, because it's
C, and your code's global name space is affected by each library (so it makes
sense for you to include the dependent libraries explicitly).
you'll know if you get something out of order, or if it's missing,
because you'll get diagnostics, but only the
first time, and after that you can forget about it.
it's easy to grep. and so on.

the scheme where each thing.c has a thing.h might to be modelled on
programming languages with modules, but each thing.o isn't normally the
unit of re-use.  most projects collect them into libraries, i'd have said.
there might be more to it, though.

for the posix scheme, the rationale must surely be that hardly anyone remembers
all the right names, let alone the right order, and things are scattered enough
or unrelated to particular things (eg, stdlib.h doesn't in practice correspond to any
particular library, and there are many includes for the C library),
so we'll let people slap them in any old way and let the system sort it out.
then there are so many variations from posix, in practice, that people add ./configure