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


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


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