Subject: Re: [boost] Interprocess regexes
From: Mike Spertus (mike_spertus_at_[hidden])
Date: 2009-12-06 15:25:58
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk