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

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2007-06-04 15:17:24

Joaquín Mª López Muñoz wrote:
>>[snip]
 >>
>> --> 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.
> 
> Why this hassle? Cannot you just use:
> 
>   T* raw=&*p;

!!! Yes, much simple. Unless operator & is overloaded. Since we can't 
produce smart references, &* should lead to a raw pointer. But if 
someday we can produce smart references this syntax is maybe dangerous. 
But I'm not saying this should not work.

> ?? This looks *far* more generic than requiring compliant smart pointers
> to go with get or get_pointer.

I agree.

> I guess these should also be corrected, since one of the requirements reads:
> 
>   "It must be convertible to a raw pointer and constructible from a raw
>   pointer."
> 
> which as you just stated is not what's actually assumed. Also, I can't finally
> figure out if you're requiring *implicit* or *explicit* construction from T*.

Ok. I agree that the definition is pretty bad.

>>>   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.
> 
> Both techniques are not equivalent... Nothing prevents one from providing,
> for instance, an allocator family whose pointer typedef is raw for some types
> an belongs to a class template X<...> for some other, thus breaking
> the pointer_to_other<> utility. If I were to standardize what kind of
> exotic allocators STL might support, I'd go with rebind.

If an allocator with value_type = T defines pointer as T* and another 
allocator with value_type = U defines the pointer type as an smart 
pointer, then we could not build node containers because we really 
construct pointer of the node type and not pointer of the value type. I 
think it's realistic and simpler to require that

allocator<X>::rebind<Y>::other::pointer

should be

pointer_to_other<X::pointer, Y>::type

>> I completely agree. I just was not expecting someone to write B.IP
>> compatible containers yet and this was on my low priority queue.
> 
> If you need a partenaire to discuss the issue with, please consider me
> a volunteer. As it currently stands (see N2284), the standard does not provide
> any clue as to what kind of allocators other than the regular ones STL
> implementors are encouraged to support (it merely states that these
> non-regular allocators might "encapsulate more general memory models
> and [...] support non-equal instances.") It'd be nice if we can come up
> with a concrete proposal to add to this encouragement section --otherwise
> it's almost impossible that future STL implementations might ever support
> B.IP!!

I've lost any hope for that ;-) Now, seriously, it would be nice to 
write a concrete proposal with other boost members to add support for 
advanced allocators to the standard. But when I proposed supporting 
advanced allocator::pointer types to the committee I didn't get much 
support. Maybe if you could make Boost.MultiIndex compatible with 
B.IP... ;-)

Regards,

Ion