This is the mail archive of the
mailing list for the GDB project.
Re: MI varobj artificial fields
A Wednesday 16 April 2008 19:51:03, Jim Ingham wrote:
> I assumed that in cases where the protections were interleaved it was
> just cruft of history, and if you were going to see protections at
> all, it would make more sense to put them in just three groups. If
> you have turn-outs, then of course it makes more sense to have three,
> since otherwise you do a little "did I turn out the right private"
> dance which is pretty annoying. There probably isn't one correct
> answer to this question.
Depends. There are good reasons why you'd want to group
your code in some other form than by protection, but that is a
What I do believe is important is for the IDE to not mess with
my class' layout when I print some type info (unless
I request it specifically with a "hide-all-private-fields"
kind of switch). That is an important peace of information
when debugging, that seems to be lost currently with the
access-is-child form? Of course, removing the nodes removes
this problem -- me, personally, as an IDE user would still
like the fields/members/methods to have some indication
of access/protection visible. Have no idea if the IDE's are
currently smart enough to gather it from parsing the sources.