Bruno Martínez ha escrito:
On Thu, 19 Jan 2006 15:39:10 -0200, Joaquín Mª López Muñoz <joaquin@tid.es> 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