From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernard Dautrevaux To: 'Nick Duffek' , ac131313@cygnus.com Cc: gdb@sources.redhat.com, insight@sources.redhat.com Subject: RE: Register group proposal Date: Fri, 23 Feb 2001 02:52:00 -0000 Message-id: <17B78BDF120BD411B70100500422FC6309E214@IIS000> X-SW-Source: 2001-02/msg00314.html > -----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 --------------------------------------------