[boost] Re:[probing interest]AssocVector (and other parts of Loki)

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