Boost logo

Boost :

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2007-06-04 06:44:48

In the section entitled "Container requirements for Boost.Interprocess
from Boost.Interprocess documentation ( ), it
stated that containers compatible with B.IP allocators must honor the

  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
  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
  ( )
  is taken into consideration.
  b. I've casually inspected the code of B.IP and seems like the
  construct/destroy interface is *not* actually used, see for instance
  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
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
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

Thank you!

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Boost list run by bdawes at, gregod at, cpdaniel at, john at