Apologies in advance, I realise I am on the verge of spamming and will not continue.
I've also had the presumptiveness to assume that in a vector of lists, the lists should use the same allocator as the vector. [...] It cannot be fixed because STL implementations do not always call allocator.construct() after allocator.allocate().
Somehow I managed to debunk myself in the space of three paragraphs. It is not possible to do what I wanted even with lists or vectors, let alone map. The reason that I risked this final post is to propose that boost needs a collection library that correctly deals with allocators. This would also have helped with boost::interprocess. The current state of affairs is painful in many respects. A lot of things would be fixed by boost::map, boost::list, boost::vector etc that wrap std::container but correctly use std::allocators, or even better, a boost::allocator model that is a superset of std::allocator. There are many many issues with this, I realise. For instance, what to do with allocators in operator=, copy-construction using a different allocator from the original and so on. Anyway, you guys arent the only ones that are getting tired of this, so.. Cheers, Christian.