From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22643 invoked by alias); 17 Feb 2008 19:55:24 -0000 Received: (qmail 22634 invoked by uid 22791); 17 Feb 2008 19:55:23 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 17 Feb 2008 19:54:57 +0000 Received: from kahikatea.snap.net.nz (194.31.255.123.static.snap.net.nz [123.255.31.194]) by viper.snap.net.nz (Postfix) with ESMTP id CEBB73DA3BA; Mon, 18 Feb 2008 08:54:49 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 831D78FC6D; Mon, 18 Feb 2008 08:54:49 +1300 (NZDT) From: Nick Roberts To: Vladimir Prus Cc: Daniel Jacobowitz , gdb@sources.redhat.com Subject: Re: Variable objects and STL containers In-Reply-To: <200802171014.18612.ghost@cs.msu.su> References: <18343.64413.689019.489727@kahikatea.snap.net.nz> <18357.23056.842755.97621@kahikatea.snap.net.nz> <18359.32130.501577.586179@kahikatea.snap.net.nz> <200802171014.18612.ghost@cs.msu.su> X-Mailer: VM 7.19 under Emacs 22.1.90.2 Message-Id: <20080217195449.831D78FC6D@kahikatea.snap.net.nz> Date: Sun, 17 Feb 2008 19:55:00 -0000 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-02/txt/msg00119.txt.bz2 > > Actually it looks doable for lists, maps etc if the children of a variable > > object were stored as a list rather than a vector. This is so that a new > > child can be added, or an old one deleted, at any point in the list. > > > > Ironically, the children were previously stored in a linked list and I > > guess vectors were used because Nathan Sidwell has created an API in C for > > them. There doesn't appear to be a similar API for lists, but since they > > are more flexible, would it be possible to revert var->children to a > > linked list? > > I'm afraid I don't see any such flexibility. Can you clarify? The vectors > were used because they allowed to eliminate lots of custom list handling > code, and I'm reluctant to go back. I can understand that you are reluctant to go back but I'm surprised that you don't see the convenience. Until now the number of children has been fixed, so vectors are probably a natural choice. With STL containers the number changes and and it becomes advantageous to use lists. Taking maps, for example, they appear to be stored as binary trees and GDB can traverse the tree (inorder) to examine all the nodes. When it finds a new one, it needs to create a new child *at that point* in the sequence of children. A vector can't do that. It can only add or remove them at the end, so a list must be used. -- Nick http://www.inet.net.nz/~nickrob