Subject: Re: [boost] Interprocess regexes
From: Mike Spertus (mike_spertus_at_[hidden])
Date: 2009-12-06 08:26:31
John Maddock <john <at> johnmaddock.co.uk> writes:
> >> while the custom allocators let you put std::containers in shared memory
> >> they are still not very useful since they can only be used by the process
> >> that put them there - other processes will (potentially) see the shared
> >> memory at a different address and all the pointers will be wrong
> > Isn't this *exactly* what the allocator's nested ::pointer type is for?
> Maybe, but it's use would be pretty limited. The std lib is entitled to
> assume that:
> "The typedef members pointer, const_pointer, size_type, and difference_type
> required to be T*,T const*, size_t, and ptrdiff_t, respectively"
> So I wouldn't be able to use any std lib containers within regex if we were
> to allow the ::pointer type to be useful
> And boost::shared_ptr, while allocating it's memory via an allocator is
> completely agnostic about it's type, so I couldn't use any smart pointer
> classes either
> So... all I would need to do is reimplement the std lib, and shared_ptr
> etc... or maybe not!
(1) boost::interprocess has done it for you already a complete set of STL-
compliant containers that are guaranteed to respect the pointer typedef.
(2) The Microsoft/Dinkumware standard libraries included with Visual C++
respect the pointer typedef.
(3) In fact, other boost containers such as Boost::unordered promise to
respect the pointer typedef. See
(4) Finally, in C++0x, all container will be required to respect the pointer
typedef (It removes the words you quote above).
Have you ever even used Boost::interprocess? Just to be clear, we use STL
containers in position-independent shared memory segments every day. For the
reasons given above, there are perfectly safe ways to ensure your standard
containers and strings (except for regex) respect the pointer typedef.
You can see loads of examples of perfectly safe and unrestricted storage of
standard containers in position-independent shared-memory segments at
Really, the points you raise are complete non-issues in practice with great
support. By contrast, the lack of an allocator in regex is a big problem with
no support either in Boost or the standards.
> Which is not to say that having an allocator for other purposes isn't
> Cheers, John.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk