In the section entitled "Container requirements for Boost.Interprocess allocators" from Boost.Interprocess documentation (http://tinyurl.com/2bruhb ), it is stated that containers compatible with B.IP allocators must honor the following conditions: 1. STL containers may not assume that memory allocated with an allocator can be deallocated with other allocators of the same type [...] 2. Containers' internal pointers should be of the type allocator::pointer and containers may not assume allocator::pointer is a raw pointer. 3. All objects must be constructed-destroyed via allocator::construct and allocator::destroy functions. I see two problems with requirement 3: a. Chances are that allocator member functions construct, destroy and address be deprecated in C++0x, if the N2257 paper by Matt Austern (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html ) is taken into consideration. b. I've casually inspected the code of B.IP and seems like the allocator construct/destroy interface is *not* actually used, see for instance list_alloc in boost/interprocess/containers/list.hpp So, if condition 3 is not used, I wonder what the actual requirements are with respect to allocator::pointer. I guess the main assumption B.IP containers work on is that allocator::pointer is implicitly convertible to/from T*. Also, what the requirements are when handling (nonraw) pointers to types other than T? Consider the following: struct T { X x; }; If I've got an allocator::pointer pt to an object t of type T and want to store a nonraw pointer to x, how should I do? I guess something like: allocator::rebind<X>::other::pointer px=pt->x; but this is just a guess from my part, as it's not documented. Some clarifications on these issues, and maybe a rewriting of the relevant doc sections, would be welcome for those container writers willing to become B.IP allocator compatible. Thank you! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo