From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9845 invoked by alias); 16 Apr 2008 16:27:01 -0000 Received: (qmail 9833 invoked by uid 22791); 16 Apr 2008 16:26:59 -0000 X-Spam-Check-By: sourceware.org Received: from imr1.ericy.com (HELO imr1.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 16 Apr 2008 16:26:32 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m3GGQTe4014014; Wed, 16 Apr 2008 11:26:30 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Apr 2008 11:26:29 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: MI varobj artificial fields Date: Wed, 16 Apr 2008 18:22:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA04291077@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <200804161735.56386.apoenitz@trolltech.com> From: "Marc Khouzam" To: =?utf-8?B?QW5kcsOpIFDDtm5pdHo=?= , 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/msg00151.txt.bz2 PiBSaWdodCBub3csIHdoZW4geW91J3JlIGluIEMrKyBwcm9ncmFtIGFuZCBh c2sgZm9yIGNoaWxkcmVuIG9mIGEgdmFyb2JqDQo+IHRoYXQgaGFzIHN0cnVj dHVyZSB0eXBlLCB5b3UgZG9uJ3QgdGhlIHRoZSBmaWVsZHMuIEluc3RlYWQs IHlvdSBnZXQNCj4gInB1YmxpYyIsICJwcml2YXRlIiBhbmQgInByb3RlY3Rl ZCIgYXMgY2hpbCBkcmVuLg0KPiBbLi4uXSANCj4gU28sIEkgc3VnZ2VzdCB0 byBhbGxvdyBNSSB0byBvcHRpb25hbGx5IHN1cHByZXNzIHRob3NlIGFydGlm aWNpYWwgZmllbGRzLg0KPiBDb21tZW50cz8NCg0KSSBhbHNvIHRoaW5rIGl0 IGlzIGEgZ29vZCBpZGVhLg0KSSBhc3N1bWUgeW91IG1lYW4gZm9yIHRoZSBw cml2YXRlL3B1YmxpYyBjaGlsZHJlbiB0byBub3QgYmUgY3JlYXRlZCBhdCBh bGw/DQoNClRoYXQgd2lsbCBiZSBhbHNvIGdvb2QgYmVjYXVzZSBjaGlsZHJl bidzIG5hbWUgYXJlIG5vdyBjcm93ZGVkIHdpdGggdGhvc2UNCmludGVybWVk aWF0ZSBsZXZlbHMgZS5nLiwgZi5wdWJsaWMuYmFyLnByaXZhdGUueCBpbnN0 ZWFkIG9mIGYuYmFyLngNCg0KQXMgeW91IHNheSwgdGhpcyB3b3VsZCBiZSBv cHRpb25hbCwgc28gYXMgdG8ga2VlcCB0aGluZ3MgYmFja3dhcmRzIGNvbXBh dGlibGUsDQpyaWdodD8NCg0KPiBTaG91bGQgdGhlIGFjY2VzcyBiZSBhbiBh dHRyaWJ1dGUgb2YgdGhlIGVhY2ggY2hpbGRyZW4sIGluc3RlYWQgb2YNCj4g YmVpbmcgY2hpbGRyZW4gdGhlbXNlbHZlcz8NCg0KVGhhdCBzZWVtcyBnb29k IHRvby4NCkJ1dCBJJ20gd29uZGVyaW5nIGlmIHNvbWVvbmUgZGVidWdnaW5n IGhhcyB1c2Ugb2YgdGhhdCBrbm93bGVkZ2U/DQpJc24ndCB0aGUgdmlzaWJp bGl0eSBvZiBmaWVsZHMgb25seSBpbXBvcnRhbnQgdXAgdG8gY29tcGlsZSB0 aW1lPw0KDQoNCkJUVywgQW5kcmUgaGFkIGJyb3VnaHQgdGhpcyB1cCBhIGxp dHRsZSB3aGlsZSBiYWNrOg0KaHR0cDovL3NvdXJjZXdhcmUub3JnL21sL2dk Yi1wYXRjaGVzLzIwMDgtMDQvbXNnMDAwMDQuaHRtbA0KDQoNCk1hcmMNCg== >From gdb-return-31670-listarch-gdb=sources.redhat.com@sourceware.org Wed Apr 16 18:06:30 2008 Return-Path: Delivered-To: listarch-gdb@sources.redhat.com Received: (qmail 28209 invoked by alias); 16 Apr 2008 18:06:29 -0000 Received: (qmail 28194 invoked by uid 22791); 16 Apr 2008 18:06:28 -0000 X-Spam-Check-By: sourceware.org Received: from qnxmail.qnx.com (HELO nimbus.ott.qnx.com) (209.226.137.76) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 16 Apr 2008 18:06:11 +0000 Received: by nimbus.ott.qnx.com with Internet Mail Service (5.5.2653.19) id <2FVSAPR4>; Wed, 16 Apr 2008 14:06:08 -0400 Message-ID: <4806400B.7050905@qnx.com> From: Aleksandar Ristovski To: Vladimir Prus Cc: gdb@sourceware.org Subject: Re: MI varobj artificial fields Date: Wed, 16 Apr 2008 18:37:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) user-agent: Content-Type: text/plain; charset="utf-8" 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 Delivered-To: mailing list gdb@sourceware.org X-SW-Source: 2008-04/txt/msg00152.txt.bz2 Content-length: 1123 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 UI > 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 everything > private. Protected data is generally frowned upon. So, most often we'll have > a lonely "public" or "private" item having all the real item. > > Furthermore, even if class has a mixture of public, protected and private data, > 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). Thanks, Aleksandar Ristovski QNX Software Systems