Re: [boost] [interprocess] container requirements for B.IP allocators

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2007-06-04 10:49:05

Hi Joaquín,

Joaquín Mª López Muñoz wrote:
> 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:
> 
 >[snip]
> 
> 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

This was recently changed due to the restrictive nature of construct() 
(only copy construction, :-( ). I returned to placement new 
construction. Some committee members kindly requested my opinion when 
Matt's paper appeared and I just said that it was possible to use 
Interprocess without construct and destroy as long as the smart pointer 
is generically convertible (say, using ADL friendly get_pointer or 
requesting smart pointers to have a .get() member function to extract 
the raw pointer. The smart pointer is required to be constructible also 
from pointers to avoid also calling "address()" and other unuseful 
functions. Documentation of Boost.Interprocess is outdated and should 
reflect the new requirements.

> 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*.

Well, offset_ptr is not implicitly convertible to T* but is 
constructible (no explicit constructor) from a raw pointer. Implicit 
convertibility to a raw pointer was a major source of problems (you know 
that conversion operators are really tricky). Now the only requirement 
for the container is to use a generic function to extract the raw 
pointer. I've chosen to follow shared_ptr interface:

--> A smart pointer has a function called "get()" to extract the raw 
pointer.
--> A smart pointer defines a function called "get_pointer()" to do the 
same that can be found with ADL.

In theory, the ADL option is appropriate, but in practice ADL is quite a 
big nightmare for some compilers. Well, that's because I don't really 
understand ADL ;-)

So the requirements for B.IP allocator::pointer are the same for those 
for B.Intrusive (which are not well explained):

http://tinyurl.com/2cjvr7

> 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;

You could use rebind and also request compatibility with Boost 
pointer_to_other<> utility. pointer_to_other is just more convenient to 
write and independent from the allocator.

Although in theory making the pointer convertible from/to a raw pointer 
might seem restrictive for some theoretical applications of allocators 
(the famous but not yet implemented containers allocating nodes on 
disk), in practice I haven't seen such restrictions. For example, can 
std::vector use std::copy to copy elements pointed by an smart pointer 
when reallocating the buffer? Or it should destroy the elements with 
allocator::destroy and construct them again with allocator::construct?

My choice is to bring allocator::pointer requirements down to the earth. 
Convertibility to raw pointers also offers the advantage of using 
static_cast which are essential when trying to optimize node containers.

> 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.

I completely agree. I just was not expecting someone to write B.IP 
compatible containers yet and this was on my low priority queue. Are you 
trying to make B.MI compatible B.IP? That's going to make some 
programmers really happy ;-)

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

Regards,

Ion