Joaquin: it just occurred to me (from the thought that your stable vector could also be implemented as a wrapper on top of a vector of share ptrs where the vector iteratir stores an index and reference to vector; it's not as good impl as yours but also provides stable iters and refs) that you can provide an additional fctn release() to "export" your object from vector, with interface similar to erase and returning a shared ptr owning the node and pointing to the object within. Importing would work also in my design but not in yours, unless you import a pair of ptr, object (but that exposes your impl in the interface, not good)... I prefer emplace. Just a thought, HB Sent from my iPhone On Sep 17, 2008, at 4:56 AM, joaquin@tid.es wrote:
Ion Gaztañaga escribió:
JOAQUIN M. LOPEZ MUÑOZ wrote:
I recently wrote up the implementation of a *stable* vector, a container mimicking the interface of std::vector except that it provides iterator and reference stability at the expense of losing memory contiguity:
http://bannalia.blogspot.com/2008/09/introducing-stablevector.html
[...] Yes. I'would be interested in an Interprocess-friendly version ;-). Since it's a node-based container and competes against std::vector and its well known performance, I think stable_vector is a perfect candidate to use a bit more unconventional allocators like these (using burst allocation for nodes and reallocation for the index vector):
Ion, where can I grab allocplus source code?
And if I'm not wrong, unlike std::vector, stable_vector could support non-copyable and non-movable objects.
Well, to do that it would have to implement emplace, but that's the only requisite.
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost