This is the mail archive of the
mailing list for the GDB project.
Re: MI varobj artificial fields
- From: Jim Ingham <jingham at apple dot com>
- To: Aleksandar Ristovski <ARistovski at qnx dot com>
- Cc: Vladimir Prus <ghost at cs dot msu dot su>, gdb at sourceware dot org
- Date: Wed, 16 Apr 2008 11:21:53 -0700
- Subject: Re: MI varobj artificial fields
- References: <4806400B.firstname.lastname@example.org>
On Apr 16, 2008, at 11:06 AM, Aleksandar Ristovski wrote:
Vladimir Prus wrote:
Right now, when you're in C++ program and ask for children of a
varobjThank you for addressing this!
that has structure type, you don't the the fields. Instead, you get
"public", "private" and "protected" as children.
I don't think this makes very much sense. Presenting access
as items in the tree seems to just clutter things. Especially as in
classes are either POD, with everything public, or real classes, with
private. Protected data is generally frowned upon. So, most often
a lonely "public" or "private" item having all the real item.data,
Furthermore, even if class has a mixture of public, protected and
do we expect the user to remember the visibility of the field he's
I don't see a reason to treat them as "children", but I think the
accessibility info. could be useful as a child's attribute (as someone
suggested already). If nothing else, for clarity, one (an ide) might
to see/organize fields by accessibility (for whatever reason).
Yeah, I think this was just added so you get the organization for
free. Note that if you go switch to an attribute, the UI is going to
have to reorder the variables to get all the private ones together,
etc. The varobj code now does that for you when it puts them into
children. But there's no guarantee they'll come that way from the
debug info, and in fact they sometimes don't.
Note, BTW, I see lots of developers with classes that have public,
protected & private data, so I'm not sure that whoever is "frowning"
on various practices is having much success...