From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18212 invoked by alias); 16 Apr 2008 18:22:19 -0000 Received: (qmail 18197 invoked by uid 22791); 16 Apr 2008 18:22:19 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 16 Apr 2008 18:21:58 +0000 Received: from relay12.apple.com (relay12.apple.com [17.128.113.53]) by mail-out4.apple.com (Postfix) with ESMTP id B61682991BF6; Wed, 16 Apr 2008 11:21:53 -0700 (PDT) Received: from relay12.apple.com (unknown [127.0.0.1]) by relay12.apple.com (Symantec Mail Security) with ESMTP id 9A45A464002; Wed, 16 Apr 2008 11:21:53 -0700 (PDT) X-AuditID: 11807135-ab9bfbb000000d04-a4-480643c16561 Received: from gdbrulez.apple.com (gdbrulez.apple.com [17.201.22.244]) by relay12.apple.com (Apple SCV relay) with ESMTP id 85CB9420003; Wed, 16 Apr 2008 11:21:53 -0700 (PDT) Cc: Vladimir Prus , gdb@sourceware.org Message-Id: <31CE38D4-0B58-4ADA-8321-7AF5FA4347C6@apple.com> From: Jim Ingham To: Aleksandar Ristovski In-Reply-To: <4806400B.7050905@qnx.com> 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 19:16:00 -0000 References: <4806400B.7050905@qnx.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/msg00154.txt.bz2 On Apr 16, 2008, at 11:06 AM, Aleksandar Ristovski wrote: > 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). Yeah, I think this was just added so you get the organization for free. Note that if you go switch to an attribute, the UI is going to have to reorder the variables to get all the private ones together, etc. The varobj code now does that for you when it puts them into children. But there's no guarantee they'll come that way from the debug info, and in fact they sometimes don't. Note, BTW, I see lots of developers with classes that have public, protected & private data, so I'm not sure that whoever is "frowning" on various practices is having much success... Jim