Jeffrey Bosboom wrote:
Then I guess a better question would be, "Why don't standard library implementations properly use ::pointer?"
In 2005 I asked the GNU libstdc++ people about this, and Matt Austern replied: "The sticking point, and the reason why nobody has done this yet for libstdc++, is that nobody has spelled out precisely what requirements my_allocator<T>::pointer must satisfy. Is my_allocator::pointer allowed to have a nontrivial copy constructor? Does it have to be a POD? Can you use const_cast to convert my_allocator::const_pointer to my_allocator::pointer? Can you use static_cast to convert my_allocator<void>::pointer to my_allocator<T>::pointer? If there's an implicit conversion from D* to B*, does it necessarily follow that there's an implicit conversion from my_allocator<D>::pointer to my_allocator<B>::pointer? Martin Sobor (of Dinkumware) said: "With user-defined pointers you can't make many of the assumptions and optimizations that you can otherwise. For example, you can't assume that such pointer types are convertible to true pointers (such as void*), you might need to be prepared to deal with exceptions where they normally cannot occur, you can't use memcpy to copy objects of user-defined pointers, etc. The thread starts here: http://gcc.gnu.org/ml/libstdc++/2005-05/msg00294.html I'm pleased to read in Mike's post that this is resolved for C++0x. I don't believe this is yet implemented in GNU libstdc++ (the bug is still open). Regards, Phil.