Hi John, 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 are 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!
Fortunately, (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 http://www.boost.org/doc/libs/1_41_0/doc/html/interprocess/allocators_contai... s.html#interprocess.allocators_containers.additional_containers (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 http://www.boost.org/doc/libs/1_41_0/doc/html/interprocess/quick_guide.html#... erprocess.quick_guide.qg_interprocess_container http://www.boost.org/doc/libs/1_41_0/doc/html/interprocess/quick_guide.html#... erprocess.quick_guide.qg_interprocess_map http://www.boost.org/doc/libs/1_41_0/doc/html/interprocess/allocators_contai... s.html#interprocess.allocators_containers.containers_explained.containers_of_co ntainers http://www.boost.org/doc/libs/1_41_0/doc/html/interprocess/allocators_contai... s.html#interprocess.allocators_containers.containers_explained http://www.boost.org/doc/libs/1_41_0/doc/html/interprocess/allocators_contai... s.html#interprocess.allocators_containers.additional_containers.unordered http://www.boost.org/doc/libs/1_41_0/doc/html/interprocess/allocators_contai... s.html#interprocess.allocators_containers.additional_containers.multi_index 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 worthwhile,
Cheers, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost