On Sep 24, 2011, at 4:55 PM, Andrei Alexandrescu wrote: > > Making the allocator a part of the container type would go the STL way, and > STL allocators are essentially a failed experiment. I'm only partially clear > on why it has failed, but it does seem that part of the reason was making the > allocator a template parameter.
I think the STL allocators were perhaps a bit overly ambitious, and the resulting complexity ended up in the wrong areas. For example, because the allocator defines all types related to the allocated data--pointers to the data, etc--it seems entirely feasible to make an allocator fronting some utterly bizarre dynamic storage method, like a database. The thing is that no one actually ended up caring about this, while at the same time the complexity of the allocator design made it difficult and confusing to use. Which I believe is why we don't see many STL-like containers in the wild. All this is pure conjecture of course, but having implemented unordered_map/set from C++0x I can say with confidence that the allocator requirements were the most complicated part of the process. If anyone is interested, I can provide the code.
