This is the mail archive of the 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: MI varobj artificial fields

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 varobj
that has structure type, you don't the the fields. Instead, you get
"public", "private" and "protected" as children.

Thank you for addressing this!

I don't think this makes very much sense. Presenting access specifies in
as items in the tree seems to just clutter things. Especially as in C++,
classes are either POD, with everything public, or real classes, with
private. Protected data is generally frowned upon. So, most often we'll
a lonely "public" or "private" item having all the real item.

Furthermore, even if class has a mixture of public, protected and private
do we expect the user to remember the visibility of the field he's after?

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 choose
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...


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