iterator to std::list keeping boost::shared_ptr
Hello, I use boost::shared pointers and store them in a std::list. Now, I have some iterators which are stored in other classes. If items are inserted or deleted, the iterators become invalid. Is there a mechanism in the boost::libraries in order to update these iterators (e.g. iterators, containers)? Greetings Ernst -- ############################################### Against software patents: http://petition.eurolinux.org ###############################################
Ernst Murnleitner wrote:
Hello,
I use boost::shared pointers and store them in a std::list. Now, I have some iterators which are stored in other classes. If items are inserted or deleted, the iterators become invalid. Is there a mechanism in the
std::list iterators will only be invalidated if the item to which the iterator refers is erased.
boost::libraries in order to update these iterators (e.g. iterators, containers)?
Nothing that I know of that directly supports that sort of design. That's what shared_ptr's are for. Store the shared_ptr and the std::list& (or a shared_ptrstd::list if the lifetime is not guaranteed), then use std::find( list.begin(), list.end(), mysharedptr ) to get an iterator. Or you might look into using the new multi_index library, storing a key rather than an iterator. Jeff Flinn
Am Fr, den 31.12.2004 schrieb Jeff Flinn um 16:56:
Store the shared_ptr and the std::list& (or a shared_ptrstd::list if the lifetime is not guaranteed), then use std::find( list.begin(), list.end(), mysharedptr ) to get an iterator.
Thank you. Storing the shared_ptr and then searching the iterator would maybe take a long time, if the list is large. Faster would be to store the iterator and remove it if the entry is removed by erase(), but it becomes more difficult: I would wrap the list and the iterator in 2 new classes and store an intrusive_ptr to the new iterator. Whenever the count of the iterator/intrusive_ptr becomes 1 - that means, that the list or the other class which owned the pointer, disappeared or released the intrusive_ptr - I would erase the iterator from the remaining list or class. In this case, the iterator has to store a shared_ptr to the list and to the secont owner. I will try this, otherwise I will come back to your solution. Greetings Ernst
participants (2)
-
Ernst Murnleitner -
Jeff Flinn