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
AssocVector.
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
approach.
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,
Ion