Phil Endecott <spam_from_boost_dev <at> chezphil.org> writes:
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).
Shared memory containers are fully usable now. We just use the container implementations provided for that purpose in Boost::interprocess, which work just great. Our experience is that this is a mature production-quality implementation comparable to other Boost libraries. In particular, the relative pointer type (offset_pointer) provided by the boost::interprocess shared memory allocators obey enough of the requirements one would expect from a pointer replacement that the boost::interproces STL containers can use them. I will certainly be pleased when I can use a std::map this way (actually, I think you can with the current Dinkumware) but until then, there is absolutely no problem with using the boost::interprocess::map reimplementation instead. Mike