From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29370 invoked by alias); 17 Apr 2008 10:20:40 -0000 Received: (qmail 29360 invoked by uid 22791); 17 Apr 2008 10:20:39 -0000 X-Spam-Check-By: sourceware.org Received: from hoat.troll.no (HELO hoat.troll.no) (62.70.27.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 17 Apr 2008 10:20:16 +0000 Received: from hoat.troll.no (tedur.troll.no [62.70.27.154]) by hoat.troll.no (Postfix) with SMTP id 2CE3220BA6 for ; Thu, 17 Apr 2008 12:20:11 +0200 (CEST) Received: from gar.trolltech.de (gar.trolltech.de [10.4.0.24]) by hoat.troll.no (Postfix) with ESMTP id 0AD01209F5 for ; Thu, 17 Apr 2008 12:20:11 +0200 (CEST) From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= To: gdb@sourceware.org Subject: Re: MI varobj artificial fields Date: Fri, 18 Apr 2008 10:22:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <4806400B.7050905@qnx.com> <4E580E6F-1A74-489C-8825-C28F37BA9B55@apple.com> <200804162016.08508.pedro@codesourcery.com> In-Reply-To: <200804162016.08508.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804171221.29294.apoenitz@trolltech.com> 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/msg00169.txt.bz2 On Wednesday 16 April 2008 21:16:08 Pedro Alves wrote: > A Wednesday 16 April 2008 19:51:03, Jim Ingham wrote: > > I assumed that in cases where the protections were interleaved it was > > just cruft of history, and if you were going to see protections at > > all, it would make more sense to put them in just three groups. If > > you have turn-outs, then of course it makes more sense to have three, > > since otherwise you do a little "did I turn out the right private" > > dance which is pretty annoying. There probably isn't one correct > > answer to this question. > > > > Depends. There are good reasons why you'd want to group > your code in some other form than by protection, but that is a > bit off-topic. Indeed. As far as I am concerned any such a re-grouping is pretty much the task of the "frontend". From the "backend" I'd just expect reasonable data in some kind of order, preferably something "canonical" like the actual physical layout of the structure. Any other grouping like grouping accoding to some "protection data field" can be doen easily in the frontend. I would not expect that functionality hardcoded into the backend. > What I do believe is important is for the IDE to not mess with > my class' layout when I print some type info (unless > I request it specifically with a "hide-all-private-fields" > kind of switch). That is an important peace of information > when debugging, that seems to be lost currently with the > access-is-child form? Of course, removing the nodes removes > this problem -- me, personally, as an IDE user would still > like the fields/members/methods to have some indication > of access/protection visible. Have no idea if the IDE's are > currently smart enough to gather it from parsing the sources. Some are, but it's alway a hassle to combine data coming from two sources (say, one stream coming from a code parser and one from gdb output) - especially if neither is 100% reliable... Andre'