>>> Personally I'd rather that I have to specify 42 include files at
>>> the top of my module.
>> I *really* disagree - if nothing else, it would make porting hell,
>> because every UNIX variant would have its own list of include files
>> you'd need.
> It's not that bad, even in a modern unix with networking.

Wanna bet?

On NetBSD, mostly-current, <stdio.h> ends up including <sys/types.h>,
<machine/types.h>, <sys/cdefs.h>, <machine/cdefs.h>, <machine/ansi.h>,
<machine/endian.h>, and <sys/featuretest.h>.

Without nested inclusion, that means that I would have to explicitly
include those eight files, in some to-be-determined order, in order to
use stdio under your scheme.  (Or else that the contents of most of
them would have to be imported into stdio.h, which at *best* would be a
maintenance nightmare.)

On a handy SunOS machine, though, with a similar test, I find four
files necessary: <stdio.h> itself, plus <stdarg.h>, <va-sparc.h>, and
<stddef.h>.  (That's with gcc.)

Tell me again how this is "not that bad"?  I must have missed
something.

> One of the very real problems with the trend towards nested includes
> is that it leaves novices out in the cold when it comes to
> understanding what's truely necessary to define and/or use an
> interface.

Novices have no business defining system interfaces; for their own, of
course, it's a design decision which route to take.

As for using the interface, which is easier?  To use?  To read?  To
understand?  Which is harder for a novice programmer to fsck up?

#include <db.h>

--vs--

/* Order may be wrong - list obtained from cc -M, order guessed at. */
#include <machine/ansi.h>
#include <machine/cdefs.h>
#include <sys/cdefs.h>
#include <sys/syslimits.h>
#include <machine/limits.h>
#include <machine/types.h>
#include <sys/types.h>
#include <db.h>
/* and that's just for one particular release of NetBSD! */

> Now instead of just reading the manual page programmers learning to
> write portable code have to grub around deep in the guts of system
> includes to try and discover what's truely necessary by unravelling
> all the nested includes and learning all the true dependencies.

What on earth are you talking about?  The more you write, the more
convinced I become that one of us has grossly misunderstood the other.

As I understand it, what you are attempting to argue against is the
idea that an include file - <stdio.h>, <arpa/inet.h>, <fcntl.h>,
whatever - should itself #include anything else necessary in order for
it to function correctly.  That's certainly the idea I'm trying to
argue for.

How does making include files pull in anything they depend on force
programmers to "grub around" and learn "the true dependencies"?  In
composing this message, I learned things about NetBSD's include files
that I've never had to learn before, despite having written a lot of
clode that used those include files - things that if I've understood
you correctly and you had your way everyone using those files would
have to learn in order to even make the code even compile.

> As much as I hate to plug "commercial" standards, "The Single UNIX
> Specification" does an excellent job of defining exactly what headers
> include which others,

Now I'm *sure* one of us is misunderstanding the other.  Not even a
standards body would be crazy enough to try to specify the internals of
how include files pull in other - internal - include files.

I hope.

> If you're going to actually try and fix all these "problems" [...],
> I'd recommend at least browsing the online version of that
> specification to see if you can be compatible with it.

I might even do so, if I had a pointer to it.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B