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