|
Boost : |
From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2006-01-20 02:52:22
Bruno Martínez ha escrito:
> On Thu, 19 Jan 2006 15:39:10 -0200, Joaquín Mª López Muñoz
> <joaquin_at_[hidden]> wrote:
>
> > Bruno Martínez ha escrito:
> >
> >> I frequently do something like this:
> >>
> >> #include <list>
> >>
> >> struct part;
> >>
> >> struct whole {
> >> std::list<part*> parts;
> >> };
> >>
> >> struct part {
> >> part(whole& w) : my_whole(&w) {
> >> me =
> >> my_whole->parts.insert(my_whole->parts.end(), this);
> >> }
> >> ~part() {
> >> my_whole->parts.erase(me);
> >> }
> >> whole* my_whole;
> >> std::list<part*>::iterator me;
> >> };
> >>
> >
> > OK, but seems to me the kind of idioms you propose are best served
> > by an intrusive version of multi_index_container. The "pointer to
> > iterator"
> > feature does not help in isolation, if I'm understanding you right.
>
> If I can get an iterator from a pointer, I don't have to store the
> iterator. I just get an iterator from this. Of course, it's more clear
> using intrusive containers.
Yes, you're right, the "pointer to iterator" feature helps both with
intrusive and non-intrusive containers. I got a little confuse in my
previous post.
> Multi_index allows to work with std::set-like containers more easily. For
> example, you can search for the key, not the whole element. This is sort
> of intrusive already, and I don't see anything bad in it. Whenever the
> element knows it's contained, intrusive is clearer.
OK, you have shown a realistic scenario where the feature
is valuable, so I'm putting this into my todo list --probably
I can have it in time for 1.34, but I'm very slow writing and checking
things :) Any suggestions about the name/syntax? Something like:
iterator iter_to(const value_type& x)const;
Alas, iterator() can't be used as the name of the member function, since
it is already a nested typedef of indices.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk