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

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

JOAQUIN LOPEZ MU?Z wrote:
> 
> I haven' thought much about it, but supporting smart references
> looks like something beyond the possibilities of STL-like
> containers. Just too much depends on references being true
> references. For one, the standard *mandates* that
> allocator::reference be T&.

Yes, but proposals to overload operator.() have been submitted and even 
if they are not admitted for C++0x I'm pretty sure this issue will be 
requested again. I agree that the standard mandates allocator::reference 
be T&, but now if we try to make allocator::pointer different from T*, 
maybe allocator::reference should be relaxed. But this is not a very 
important point IMHO, I can live with any reasonable solution.

> I agree with you this assumption is reasonable enough. My point
> was merely that rebind is not guaranteed to be equivalent to
> pointer_to_other, even for legal situations. Let me propose
> another counterexample:
> 
>   template<typename T>
>   class my_allocator
>   {
>     typedef my_smart_pointer<T> pointer;
>     ...
>   }
> 
>   // out of malevolence I specialize as follows
> 
>   class my_smart_pointer_to_char
>   {
>     // same interface as my_smart_pointer<char>
>   }
>   template<>
>   class my_allocator<char>
>   {
>     my_smart_pointer_to_char pointer;
>     ...
>   };
> 
> This is legal, consistent, and breaks pointer_to_other.
> It is incredible silly, also:) but this was not my point.

Ok, it's legal. Now the standard says implementations can suppose that 
that allocator::pointer is T*, so if we are proposing a new allocator 
proposal we can require allocator<Y>::pointer to be the same as 
pointer_to_other<allocator<X>::pointer, Y>::type. My opinion is that if 
there is no reasonable use case to allow different smart pointers in in 
different allocator template specializations, we should request this 
limitation. This would allow, for example, building non-intrusive 
containers on top of intrusive containers (intrusive containers have no 
allocator, so they can use pointer_to_other<>), which is a good reason 
to request compatibility.

> [...]
>> committee I didn't get much support. Maybe if you could make
>> Boost.MultiIndex compatible with B.IP... ;-)
> 
> I don't see how this would lend support to the proposal
> in front of the committee, as B.MI is not a standard lib. But

B.IP is a rare, maniac-made silly library ;-) B.MI is widely used and 
it's the base for other nice libraries like Bimap (and I hope more 
libraries in the future). Adding B.MI to the list of advanced allocator 
friendly libraries would bring "existing practice" to another level. If 
we can add B.Intrusive also to the equation (making pointer_to_other<> 
compatible with allocator::pointer, for example) I think we have a solid 
ground to succeed. Committee members from Boost can do the rest ;-)

Regards,

Ion