(ref.doc)grumpy 010893

Newsgroups: comp.lang.c++
From: [email protected] (Paul J Lucas)
Subject: Re: Include file dependencies
Organization: AT&T Bell Laboratories
Date: Sun, 1 Aug 1993 15:27:27 GMT

From article <[email protected]>, by [email protected] (Andrew Lighten):
> I'd be interested to hear about how other people handle include file
> dependencies. Although C++ theoretically hides implementation details
> from the application, this isn't quite true when you include the header
> for a class, and this header requires additional definitions.
> 
> I modified one of my applications to include my SysCall header. The
> compile fell over because I also needed to include several other headers
> that were required by private members of some of the SysCall classes. I
> also had to include stdio.h to satisfy a private FILE* in the class.
> 
> Is nested include files the recommended solution? I suspect that it is,
> but I don't know that I quite feel good about that. I think that makefile
> maintenance could become a problem in a class library with lots of headers
> and objects.
> 
> Any comments?

	Yes, you are forced to have one header #include another.  This
	is the case for any non-trivial class hierarchy.  There is one
	corner you can cut, however.  If, in B.h, class B only has a
	pointer or reference to class A and does not call any
	member-functions in inlined members of B, then you need only
	forward-declare A:

		// B.h
		class A;	// sufficient; no need for #include "A.h"

		class B {
			A *an_A;
			// ...
		};
	
	This means that if A changes, B.h is not affected.  B.c, of
	course, would need to #include "A.h".  The advantange is that
	the files that #include "B.h" don't have to be recompiled just
	because A.h changes.  The reduces the "cascading" effect.

	If you're using vanilla 'make' (which is infuriatingly stupid),
	a solution that I've come up with for makefiles that works is to
	use make variables to manage header dependencies.  For this
	example, let us assume that B.h *does* need A.h and that C.h
	needs B.h (hence, C.h depends on A.h even though it doesn't
	directly include it):

		# makefile
		CLASS_A=	A.h
		CLASS_B=	B.h $(CLASS_A)
		CLASS_C=	C.h $(CLASS_B)

		# ...

		a.o: a.c $(CLASS_A)
		b.o: b.c $(CLASS_B)
		c.o: c.c $(CLASS_C)
	
	Such a scheme will ensure that things are always conistent and
	properly up-to-date.
-- 
	- Paul J. Lucas
	  AT&T Bell Laboratories
	  Naperville, IL