[ On Saturday, November 9, 2002 at 23:21:42 (+0100), der Mouse wrote: ]
> Subject: Re: includes question
>
> If I use foo_t in my code, I should include the header <bar.h> that
> defines it, yes.  But if I happen to use bleeble(), whose interface
> does not require me to know foo_t even exists, but bleeble() is
> declared in the same include file <fribble.h> as another call gringle()
> whose interface _does_ require its caller to know about foo_t, *then*
> should I have to include <bar.h>?  I maintain I should not.  Yet in far
> too many cases, <fribble.h> produces syntax errors if foo_t is not
> already defined.

Surely you know you live in a house of cards and that if you don't
include the right cards at the foundation then they'll all come a
tumbling down.

If the interface definition declares that thou must #include <bar.h>
before you #include <fribble.h> then that's the way it must be.

Nested #include files are really very nasty things that lead people to
make incorrect assumptions, and which can easily get in the way of other
legitimate things.  (namespace issues are but one of the problems)

After all, if you don't like all this stuff there are always dynamically
typed languages to keep you happy!  ;-)

> Concrete example: Suppose I use close(), which takes and returns an
> int, and I include <unistd.h> to prototype it.  Suppose <unistd.h> also
> prototypes fork(), whose interface uses the pid_t type.  Should I have
> to include <sys/types.h> to declare pid_t because a function I don't
> use and may not even know exists happens to need it?

So goes the tug of war between isolation of interface descriptions and
the desire to avoid having to include a thousand separate declarations
in a carefully controlled order just to write hello.c.

I think the fundamental flaw is in the use of a macro pre-processor to
slurp in "shared" declarations and type definitions just so that
separate compilation can be done efficiently and in a maintainable
fashion.  I don't know that we'll get away from doing this any time soon
though.

The alternative is to give in to the evils of nested includes and though
this will maintain the illusion of separation of some interfaces, it
will transparently produce the effect of lumping everything together
into one blob behind the scenes.  We're already half way there after all.

The only thing I really want to warn about is that the various standards
we like to admire and adhere to have sometimes got things to say about
what must be included by whom and where and in what order, it it would
not really help with compatability and portability to ignore those rules
and make things work despite them.  After all if we wanted to make
things better and avoid all this mess we'd throw it all out and start
over from scratch.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>