gdbtypes.h #defined field accessors

gdbtypes.h #defined field accessors

[Jan Kratochvil]

Hi,

I have a longterm question.  gdbtypes.h contains definitions like:

#define TYPE_N_BASECLASSES(thistype) TYPE_CPLUS_SPECIFIC(thistype)->n_baseclasses
#define TYPE_CPLUS_DYNAMIC(thistype) TYPE_CPLUS_SPECIFIC (thistype)->is_dynamic

Why the code does not use directly the right hand side?  It would even have
the same (in some cases shorter, in some cases longer) statements length:

  f (TYPE_N_BASECLASSES (type), TYPE_CPLUS_DYNAMIC (type);
->
  struct cplus_struct_type *cplus = TYPE_CPLUS_SPECIFIC (type);
  f (cplus->n_baseclasses, cplus->is_dynamic);

I have only an idea to permit turning direct field into a getter such as is:

#define TYPE_CPLUS_SPECIFIC(thistype) \
   (!HAVE_CPLUS_STRUCT(thistype) \
    ? (struct cplus_struct_type*)&cplus_struct_default \
    : TYPE_RAW_CPLUS_SPECIFIC(thistype))

Coccinelle makes such later transformation automatic even without any macros.
Should new fields still follow this paradigm?

On Thu, 17 Jun 2010 04:31:57 +0200, Tom Tromey wrote:
# It is customary to make new wrapper macros for new fields here.
# I'm not sure that adds much benefit, but maybe just consistency is a
# good enough reason.


Thanks,
Jan

Re: gdbtypes.h #defined field accessors

[Tom Tromey]

>>>>> "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

Re: gdbtypes.h #defined field accessors

[Joel Brobecker]

> In new code I don't generally write accessors.

I don't know if this is relevant to this particular discussion, but
I tend to like opaque structures and accessors (setter/getter) functions,
and I try to use that when writing new code.  The idea is that it's just
very easy to figure out who's reading the data, and who's modifying it.
Sometimes, it's the only way to go, because the data structures are
complex enough that we shouldn't expose their contents, but even for
simple data structures, this can be handy.

-- 
Joel

Re: gdbtypes.h #defined field accessors

[Tom Tromey]

Joel> I don't know if this is relevant to this particular discussion, but
Joel> I tend to like opaque structures and accessors (setter/getter) functions,
Joel> and I try to use that when writing new code.  The idea is that it's just
Joel> very easy to figure out who's reading the data, and who's modifying it.
Joel> Sometimes, it's the only way to go, because the data structures are
Joel> complex enough that we shouldn't expose their contents, but even for
Joel> simple data structures, this can be handy.

Yes, I agree.  I was really referring to macro accessors.

Opaque data structures plus accessors can make for very nice APIs.
Still, some care must be taken -- struct value is a particularly bad
example, because although it is nominally opaque, in reality the API is
quite large and lets users do too much.

Jan> While it is not relevant to your "new code" note this is what I
Jan> miss on the GDB accessors - they would be (more) useful separated
Jan> into getters/setters.  It would easily enable providing various
Jan> currently constant fields as dynamic DWARF blocks.

Agreed.  This has been a problem for me when hacking GCC and Emacs as
well -- both of which use "both lvalue and rvalue" macro accessors.
This is one area where value, as gross as is it, is distinctly better.

Tom

Re: gdbtypes.h #defined field accessors

[Jan Kratochvil]

On Mon, 28 Jun 2010 22:37:47 +0200, Tom Tromey wrote:
> Though FWIW, little of the GDB work I've done seems amenable to automation,
> even the grungy add-an-argument-to-val_print stuff :-(

I have to agree...


> I tend to stick with the style of a given module.
> 
> In new code I don't generally write accessors.

OK.


On Mon, 28 Jun 2010 22:57:01 +0200, Joel Brobecker wrote:
> > In new code I don't generally write accessors.
> 
> I don't know if this is relevant to this particular discussion, but
> I tend to like opaque structures and accessors (setter/getter) functions,
> and I try to use that when writing new code.

While it is not relevant to your "new code" note this is what I miss on the
GDB accessors - they would be (more) useful separated into getters/setters.
It would easily enable providing various currently constant fields as dynamic
DWARF blocks.


Thanks,
Jan