Boost logo

Boost :

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

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



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