From: Nick Roberts <nickrob@snap.net.nz>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: Daniel Jacobowitz <drow@false.org>, gdb@sources.redhat.com
Subject: Re: Variable objects and STL containers
Date: Sun, 17 Feb 2008 19:55:00 -0000 [thread overview]
Message-ID: <20080217195449.831D78FC6D@kahikatea.snap.net.nz> (raw)
In-Reply-To: <200802171014.18612.ghost@cs.msu.su>
> > 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
next prev parent reply other threads:[~2008-02-17 19:55 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-05 6:01 Nick Roberts
2008-02-05 6:17 ` Vladimir Prus
2008-02-05 6:34 ` Nick Roberts
2008-02-05 6:56 ` Vladimir Prus
2008-02-05 13:16 ` Daniel Jacobowitz
2008-02-15 9:24 ` Nick Roberts
2008-02-17 0:19 ` Nick Roberts
2008-02-17 7:14 ` Vladimir Prus
2008-02-17 19:55 ` Nick Roberts [this message]
2008-02-18 8:12 ` Vladimir Prus
2008-02-19 16:31 ` Daniel Jacobowitz
2008-02-05 11:31 ` Mark Kettenis
2008-02-05 12:03 ` Vladimir Prus
2008-02-05 13:18 ` Daniel Jacobowitz
2008-02-08 0:53 ` Nick Roberts
2008-02-08 6:47 ` Vladimir Prus
2008-02-10 4:28 ` Nick Roberts
2008-02-10 7:11 ` Vladimir Prus
2008-02-10 17:52 ` Daniel Jacobowitz
2008-02-10 18:14 ` Vladimir Prus
2008-02-10 19:45 ` Doug Evans
2008-02-10 19:44 ` Doug Evans
2008-02-10 20:05 ` Vladimir Prus
2008-02-10 21:02 ` Nick Roberts
2008-02-11 9:12 ` Vladimir Prus
2008-02-11 13:07 ` Daniel Jacobowitz
2008-02-11 20:28 ` Nick Roberts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080217195449.831D78FC6D@kahikatea.snap.net.nz \
--to=nickrob@snap.net.nz \
--cc=drow@false.org \
--cc=gdb@sources.redhat.com \
--cc=ghost@cs.msu.su \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox