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