Gregory Colvin <[EMAIL PROTECTED]> writes:
On Tuesday, Sep 2, 2003, at 09:22 America/Denver, David Abrahams wrote:...
I think you're missing my point. There's no reason that a stateful allocator<T> should have access to the state data required to allocate U objects, but that's the status quo.
I'm probably missing your point, but the idea is that a container needs to allocate various kinds of things, and they all get allocated with the same allocator, either directly or via rebind.
For instance, maybe you are are using memory-mapped files as a persistent storage. The Ts and the Us and whatever the container needs all have to go into the same file, so the allocator<T> and all its rebinds must know which file to use and how.
...It's a conceptual mess.
Alex didn't have MPL when he invented allocators. So they are messier than they need to be, but I still say they are not so bad as you claim
Are you saying my factual claims are wrong, or just that all those issues don't amount to a very important problem?
Just that it doesn't look nearly as messy to me as it does to you.
and that it would be easier for the next standard to repair them than to replace them.
That may be, but we're here at Boost, talking about the interface we should be using in Boost components.
Yep. I still think UserAllocator is a good default, and that where it doesn't suffice there is some value to playing nicely with STL.
So even when we come up with some beautiful new thing to do the allocation job better, we will still need adaptors both ways, so that one can get an allocator from an STL container and turn it in to one of our new things, or take one of our new things and turn it into an allocator to use in an STL container.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
