Both statements do not refute the original proposition, which is that we need a way to sometimes allocate from the stack or from a block of given memory.
I think that if we can't have either/both, then there is something wrong with STL.
I agree that allocating from a specified block is a good use case, but I don't think "wrong with the STL" is an appropriate sentiment. As Ross points out there are some serious gotcha's when attaching an allocator object to existing memory (stack or otherwise), and this is certainly not the run-of-the-mill usage that would be expected by the STL. I think that there is room for both allocator models here. You just have to be very careful about how they work. For example, it may be worthwhile to attach the allocator to its container to help prevent the possibility of multiple containers accidentally drawing from the same memory pool. Not that I think that I will win over STL; but wasn't the "point" of
allocators such that we could do things like this?
Maybe yes, maybe no. My understanding of the allocators was that they were originally used to abstract differences in pointer types like __far and __huge pointers. Their usage has become substantially more complex and varied since then. Andrew Sutton andrew.n.sutton@gmail.com