This is the mail archive of the
mailing list for the GDB project.
Re: MI varobj artificial fields
What we did at Apple was that we added a setting "set mi-show-
protections" that "auto-opened" all public/protected/private
children. So if you have a class:
-var-create - * mine
So if you want you can still show the protections in the UI, but you
don't have to add a separate step to open them up. I don't see why
the presence of "private" etc. really much matters in varobj child
names that are after all only for machine consumption. But it is
annoying to have to go through two steps to see the contents.
Another thing we did was that if the class ONLY had public members
then we automatically suppress the protections. That avoids having
"public" show up for:
which was kind of dopey.
On Apr 16, 2008, at 9:26 AM, Marc Khouzam wrote:
Right now, when you're in C++ program and ask for children of a
that has structure type, you don't the the fields. Instead, you get
"public", "private" and "protected" as chil dren.
So, I suggest to allow MI to optionally suppress those artificial
I also think it is a good idea.
I assume you mean for the private/public children to not be created
That will be also good because children's name are now crowded with
intermediate levels e.g., f.public.bar.private.x instead of f.bar.x
As you say, this would be optional, so as to keep things backwards
Should the access be an attribute of the each children, instead of
being children themselves?
That seems good too.
But I'm wondering if someone debugging has use of that knowledge?
Isn't the visibility of fields only important up to compile time?
BTW, Andre had brought this up a little while back: