Chris> there are major issues, to do with when, or how, assignment, construction and swapping move allocators around. There has been some serious discussion and research on this issue previously.
And I don't pretend to be an expert on all the issues. From wikipedia: ``Stepanov later commented that, while allocators "are not such a bad ideas in theory (...) [u]nfortunately they cannot work in practice". He observed that to make allocators really useful, a change to the core language with regards to references<http://en.wikipedia.org/wiki/Reference_%28computer_science%29>was necessary`` However, at the end of the day, this specific proposal works very well without changing anything. The key motivation for the proposal was to make fast and small nested containers that can use the stack and/or heap for storage, and to make deallocation a no-op. This has been accomplished with just one storage used by a set of containers at or below a given stack frame, and also by having multiple storage areas that the programmer is required to keep seperate. This is not a huge burden, and is in fact a very simple thing to acheive in the scheme of things. Can it be abused? Yes. But you can also dereference a freed pointer.
Not to say it can't be fixed, but it isn't just a case of "oh yes, just say they respect it".
I really didn't mean to trivialise the issue. I realise that the idea of allocator equivalence has many issues, and it will be smarter people than I whom decide on them. I'm just making the point that it doesn't adversely affect the key aspects of this proposal. All of my performances tests to date have used one storage with one or more containers, have been completely safe (after adding correct alignment) and standards-based, and have shown measurable and repeatable benefit. I very clearly stand to be corrected on all results that I have posted.
Chris
Cheers, Christian.