RE: Register group proposal

[Bernard Dautrevaux <Dautrevaux@microprocess.com>]

> -----Original Message-----
> From: Nick Duffek [ mailto:nsd@redhat.com ]
> Sent: Thursday, February 22, 2001 7:24 PM
> To: ac131313@cygnus.com
> Cc: gdb@sources.redhat.com; insight@sources.redhat.com
> Subject: Re: Register group proposal
> 
> 
> On 22-Feb-2001, Andrew Cagney wrote:
> 
> >And that illustrates the problem - why should "abc.h" suck in "xyz.h"
> >when clients of "abc.h" may not use any of "xyz"'s methods.
> 
> So that we may use typedefs in the standard and obvious manner.
> 
> What's the problem with "abc.h" sucking in "xyz.h"?  The 
> usual "#ifndef
> abc_h" envelope takes care of multiple-inclusion problems.

Perhaps for avoiding an unneeded dependency, that would trigger superfluous
recompiles of users of "abc.h" that do not need "xyz.h" if "xyz.h" is
modified? note that if your dependencies are kept up to date (something I
hope is true) you also end up with a lot bigger dependency lists, and thus
slower "make" processes, even if everything is already up-to-date ;-(

Another problem may be seen as "name space pollution": If you don't mind
about "xyz.h" why should you be prevented using some identifiers colliding
with the private parts of it?

As a rule of thumb, a header should only #include things it really NEEDS,
and try to avoid these as far as possible.

My 0.02$

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
--------------------------------------------