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

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:

class Foo
    int first;
    int second;
    int third;

-var-create - * mine
^ done ,name = "var2 ",numchild = "3 ",type = "Foo ",typecode = "STRUCT ",dynamic_type = "",in_scope ="true",block_start_addr="0x00001cfc",block_end_addr="0x00001d70"
-var-list-children var2

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:

struct foo

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 varobj
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 fields.

I also think it is a good idea.
I assume you mean for the private/public children to not be created at all?

That will be also good because children's name are now crowded with those
intermediate levels e.g., instead of

As you say, this would be optional, so as to keep things backwards compatible,

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:


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