From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13449 invoked by alias); 16 Apr 2008 18:18:08 -0000 Received: (qmail 13441 invoked by uid 22791); 16 Apr 2008 18:18:07 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 16 Apr 2008 18:17:40 +0000 Received: from relay12.apple.com (relay12.apple.com [17.128.113.53]) by mail-out3.apple.com (Postfix) with ESMTP id 30379286775C; Wed, 16 Apr 2008 11:17:39 -0700 (PDT) Received: from relay12.apple.com (unknown [127.0.0.1]) by relay12.apple.com (Symantec Mail Security) with ESMTP id 1783C464002; Wed, 16 Apr 2008 11:17:39 -0700 (PDT) X-AuditID: 11807135-a89b9bb000000d04-e2-480642c21f0a Received: from gdbrulez.apple.com (gdbrulez.apple.com [17.201.22.244]) by relay12.apple.com (Apple SCV relay) with ESMTP id ECDB9420004; Wed, 16 Apr 2008 11:17:38 -0700 (PDT) Cc: =?ISO-8859-1?Q?Andr=E9_P=F6nitz?= , gdb@sourceware.org Message-Id: <18AEA6D3-19E5-460A-86FC-8B83FA809474@apple.com> From: Jim Ingham To: Marc Khouzam In-Reply-To: <6D19CA8D71C89C43A057926FE0D4ADAA04291077@ecamlmw720.eamcs.ericsson.se> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.919.2) Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: MI varobj artificial fields Date: Wed, 16 Apr 2008 18:51:00 -0000 References: <6D19CA8D71C89C43A057926FE0D4ADAA04291077@ecamlmw720.eamcs.ericsson.se> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00153.txt.bz2 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