From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Faylor To: Bernard Dautrevaux Cc: "'Nick Duffek'" , gdb@sources.redhat.com, insight@sources.redhat.com Subject: Re: Register group proposal Date: Mon, 26 Feb 2001 09:28:00 -0000 Message-id: <20010226122752.M1296@redhat.com> References: <17B78BDF120BD411B70100500422FC6309E218@IIS000> X-SW-Source: 2001-02/msg00369.html On Mon, Feb 26, 2001 at 02:10:25PM +0100, Bernard Dautrevaux wrote: >> -----Original Message----- >> From: Nick Duffek [ mailto:nsd@redhat.com ] >> Sent: Sunday, February 25, 2001 12:52 AM >> To: Dautrevaux@microprocess.com >> Cc: gdb@sources.redhat.com; insight@sources.redhat.com >> Subject: RE: Register group proposal >> >> >> On 23-Feb-2001, Bernard Dautrevaux wrote: >> >> >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? >> >> I agree that's a pain. But prohibiting typedefs only avoids a small >> subset of superfluous recompiles. For example, changing a >> single macro in >> gdbarch.h causes a massive rebuild. >> >> Eventually, GCC probably will support header file compilation, which >> probably will lead to fully-accurate dependency generation. This will >> eliminate superfluous recompiles. >> >> In the meantime, the problem diminishes as hardware speedups >> outpace GCC >> complexity. >> >> However, humans won't ever get better at writing maintainable code or >> understanding existing code. Typedefs help us achieve both of those >> goals. > >I must say that, although it's a bit shorter, I don't see a real advantage >to define some interface type xxx for > >(1) typedef struct { ... } xxx; > void f(xxx*); > >and > >(2) struct xxx; > void f(struct xxx*); That works fine if xxx is a struct. If, at some point, you have an amazing idea that allows you to change all xxx's to "unsigned short" you're stuck with a lot of editing. cgf