From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10138 invoked by alias); 30 Apr 2008 08:59:00 -0000 Received: (qmail 10129 invoked by uid 22791); 30 Apr 2008 08:58:58 -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; Wed, 30 Apr 2008 08:58:39 +0000 Received: from hoat.troll.no (tedur.troll.no [62.70.27.154]) by hoat.troll.no (Postfix) with SMTP id 5DB322081B for ; Wed, 30 Apr 2008 10:58:35 +0200 (CEST) Received: from gar.trolltech.de (gar.trolltech.de [10.4.0.24]) by hoat.troll.no (Postfix) with ESMTP id 44F3F20816 for ; Wed, 30 Apr 2008 10:58:35 +0200 (CEST) From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= To: gdb-patches@sourceware.org Subject: Re: [PATCH:MI] Return a subset of a variable object's children Date: Wed, 30 Apr 2008 10:47:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <18452.24568.655617.907458@kahikatea.snap.net.nz> <18455.41299.899430.615138@kahikatea.snap.net.nz> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804301100.21674.apoenitz@trolltech.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00688.txt.bz2 On Wednesday 30 April 2008 08:24:30 Vladimir Prus wrote: > Nick Roberts wrote: > > [...] > > I was thinking that only a small number of children would ever exist > > simultaneously. Scrolling might make that a larger number but maybe > > it could be arranged to delete children that go out of view. > > I wonder if deleting children that are not visible is possible/desirable. Well, I would still prefer a simple toggle that would allow me to switch off any automatic creation of children and one-shot 'expression evaluation' and one-shot 'children listing'. I would expect this to be much simpler to implement on the gdb side and gives all the flexibility needed (as far as I am concerned) on the frontend side. Complex containers may do all kind of funny stuff behind the debugger's back (like reallocation, rebalancing, renumbering, moving stuff to and from secondary memory) which a frontend might want to handle transparently. I would not expect gdb to even be aware of that (let alone to handle(!) it). Also, hard-wiring behaviour to certain types calls for trouble on the frontend side. E.g. if there's a std::string member somewhere I might want to see it as something "human readable" (-> 1 child), or a byte array (->lots of children), or maybe a structured view if it is XML (-> some children). So whatever behaviour is hard-wired will be wrong for n - 1 use cases. Regards, Andre'