Boost logo

Boost :

Subject: Re: [boost] request for interest: stable vector
From: Herve Bronnimann (hervebronnimann_at_[hidden])
Date: 2008-09-17 08:01:02

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_at_[hidden] wrote:

> Ion Gaztañaga escribió:
>>> 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:
> [...]
>> 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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at