[ On Sun, June 14, 1998 at 18:39:18 (-0400), der Mouse wrote: ]
> Subject: Re: problems with arpa/inet.h
>
> > 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.  It does get
unmanagable with X11, but that's where one header per library starts to
make the most sense.  GUI APIs are almost by definition huge and
unmanageable (not all, eg. Plan 9's various).

Truly portable programming *still* requires lots of #ifdef'd #includes
to get the right things in place, and unfortunately "prototypes" have
only made this *more* difficult.

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.  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.  Luckily some systems still
document all the true dependencies even though they may offer shortcuts
through nested includes.  Nested includes are *truly* evil.

That said though I agree that we'll never banish nested includes from
unix and unix-compatible systems.

>  (Go look at a .depend file sometime - unless you've made a
> point of grubbing around in the include file mechanisms, I'll bet
> you've never even *heard* of some of the files you're including without
> knowing it - and that you'd have to know about under this paradigm.)

I've spent far more time than I care to admit grubbing through the
headers of almost all the variants of Unix (and as I mentioned, on
occasion other things too, such as even early MS-Windows).

> Fortunately, it's actually not as bad as you paint it.  I've been going
> thorugh and adding "missing" includes to the include files as I trip
> over them.  And while I've doubtless failed to notice some because I
> "always" want the "missing" file anyway, and they happen to be such
> that my style puts the needed #include before the other...despite that,
> I still regularly find that when I start a new program and try to
> compile it with no #includes, then start adding them as necessary,
> there are at least half a dozen functionally orthogonal sets.

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, and they seem to have reduced the number of
#includes necessary down to the bare minimum.  If you're going to
actually try and fix all these "problems" to the point where your fixes
are generally useful (at least in some definition of "useful"), I'd
recommend at least browsing the online version of that specification to
see if you can be compatible with it.

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>