This is the mail archive of the
insight@sources.redhat.com
mailing list for the Insight project.
RE: Register group proposal
- To: 'Nick Duffek' <nsd at redhat dot com>, ac131313 at cygnus dot com
- Subject: RE: Register group proposal
- From: Bernard Dautrevaux <Dautrevaux at microprocess dot com>
- Date: Fri, 23 Feb 2001 11:34:39 +0100
- Cc: gdb at sources dot redhat dot com, insight at sources dot redhat dot 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
--------------------------------------------