This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfc] block.{h,c}


Can it eventually contain the few remaining scraps of block* code found in blockframe.c (hint, hint :-)?

I'd like to move 'struct block' out of symtab.h into a new file
block.h, and creating a new file block.c with block-specific
functions.  Doing so would help lessen compilation dependencies, which
is important for people like me with slow computers: right now
symtab.h is included by around 140 files, while the resulting block.h
would only be included by around 40 or so.  Basically, my code
organization philosophy says that you should only define two different
structures in the same include file if they are very closely linked
(e.g. if code that refers one would almost always refer to the other);
symtab.h doesn't pass that test.  For example, there's no particular
reason why code using 'struct block' would be particluarly like to use
'struct minimal_symbol', or vice-versa.

I don't feel _too_ strongly about this; on the other hand, I can't see
any reason not to make this change other than inertia.  (I guess that,
the more include files there are, the more possibility there is that
Makefile.in could get out of sync; that's not a good reason, though,
and maybe the ARI could check for that?)

I think it is consistent with GDB's current overall direction - more modula with *.[hc] relating to specific objects or sets of objects.


Andrew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]