That would Ion. See https://github.com/boostorg/container/blob/master/meta/libraries.json for contact details.
Cool, thanks!
When someone supplies a stateless allocator, like std::allocator<T>, the sizeof(allocator) is still 1 and thus the size of your container object is increased by 1 when it doesn't need to be. The EBCO (or compressed_pair) can be used here to make sure that empty allocators do not add the extra +1 byte to your container object storage. This is also a commonly used technique in C++ standard library implementations, as well as in many Boost libraries that support custom allocators and custom deleters.
If you could help me with some basic code here, I'd appreciate it- I understand what you're saying, but am unsure whether you're meaning to wrap the allocator instance, or something else entirely.
My general feeling is more in line with Mike Acton's in that if something throws, you've got a problem anyway - peaceably unrolling isn't really helping anyone.
You're actually misunderstanding Mike completely, and out of context.
I'm pretty sure I'm not - I watched the entirety of his Data Driven Design speech at cppcon - several times - and if you watch that he's very specific.
Writing generic code around T (value type) or A (allocator type) requires that you handle things like this. As I mentioned, the C++ standard library containers do this. So do Boost library containers. If you do things like both allocate and construct, and construction throws, and the user of your library has no way to deallocate what you've allocated, it completely alienates them using your container in any of their generic code where they support T types whose constructors can throw, etc.
That's fine, it's just not something I immediately felt was important, but I can see that it is for boost- thanks again, Matt