Re: MI varobj artificial fields

[Jim Ingham <jingham@apple.com>]

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
{
   public:
     int first;
   protected:
     int second;
   private:
     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"
(gdb)
-var-list-children var2
^done,numchild="3",children=[child={name="var2.public.first",exp="first",numchild="0",type="int",typecode="INT",dynamic_type=""},child={name="var2.private.third",exp="third",numchild="0",type="int",typecode="INT",dynamic_type=""},child={name="var2.protected.second",exp="second",numchild="0",type="int",typecode="INT",dynamic_type=""}]

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.

Jim

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.
>> Comments?
>
> 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., f.public.bar.private.x instead of f.bar.x
>
> As you say, this would be optional, so as to keep things backwards  
> compatible,
> right?
>
>> 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:
> http://sourceware.org/ml/gdb-patches/2008-04/msg00004.html
>
>
> Marc