Boost logo

Boost :

From: ION_G_M (ION_G_M_at_[hidden])
Date: 2005-02-02 02:28:09

>Since there are people working on a, b, d and e, I would like to ask
>the following questions:
>0) Are you interested in adding AssocVector to Boost?
>(there seems to be at least _some_ interest[1])

Yes I would be, since I'm using it in Boost Shmem.

>1) Is there interest in additional interfaces(set, multiset, multimap)
>described in [1] or is std::map-like container enough?

I would see this also very useful, since associative containers are
normally developed as a single underlying class that can be, via
traits, converted into multi* or *map/set.

Since assoc_vector or the new container family will be based on a
vector implementation, I would suggest providing a common vector-like
class that uses the following:

-> No raw pointers. Uses allocator::pointer instead
-> No placement news or destructors. Uses allocator::construct/destroy
-> To sum up: all memory operations done using allocator interface so
that for example, can be used in shared memory using relative pointers.

 While doing some tests, I was able to modify slightly yasli_vector to
provide this (allocator/pointer) != (new(ptr)/T*) approach. Maybe it
could be a good start point. For a modified SGI vector implementation
using this approach, please see shmem_vector in Boost Shmem library in
Files Section. shmem_assoc_vector is basically the same as Loki

 If this vector is also developed for Boost to construct the
AssocVector/flat_associative containers, I would be glad to drop the
shmem_vector and shmem_assoc_vector classes from Boost Shmem, since
they only modify SGI implementations to use the generic allocator

 I would also point out that apart from set/map operations, the new
family should have reserve/capacity methods to optimize memory usage
and avoid reallocations if the user knows the number of elements to
insert. Just a call to vector::reserve/capacity
 I've been also talking with Daniel James, who is responsible of Boost
unordered associative family and he is also generously using this
allocator::pointer/construct/destroy generic approach, so we will be
able to use boost unordered family in shared memory, mapped in
different base addresses, using relative smart pointers.

Best regards,


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