This is the mail archive of the gdb@sourceware.org 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: gdbtypes.h #defined field accessors


>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> #define TYPE_N_BASECLASSES(thistype) TYPE_CPLUS_SPECIFIC(thistype)->n_baseclasses

Jan> Why the code does not use directly the right hand side?

I'm not sure I know the real answer.

I think this was a kind of GNU style thing for a while.  GCC is still
heavily macroized this way, nearly all fields go through accessors.

In GCC I think this has enabled some refactorings.  And, I think I've
run across internal evidence in GDB that this was done as well --
specifically that type and main_type used to be the same but were split
apart.

I'm not sure the argument for this macroization is very strong in GDB,
though.  They are somewhat nice in that they can let you easily find all
the users of a field -- but they aren't always uniformly used (ISTR some
of the symbol accessors are not used universally), and there may be
other ok ways to get that info.

Jan> Coccinelle makes such later transformation automatic even without
Jan> any macros.

Yeah.  Or now that GCC has decent column information, you can even do
fun stuff just parsing its error messages.  Though FWIW, little of the
GDB work I've done seems amenable to automation, even the grungy
add-an-argument-to-val_print stuff :-(

Jan> Should new fields still follow this paradigm?

I tend to stick with the style of a given module.

In new code I don't generally write accessors.

Tom


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