----- Mensaje original ----- De: Ion Gaztañaga <igaztanaga@gmail.com> Fecha: Lunes, Junio 4, 2007 9:17 pm Asunto: Re: [boost] [interprocess] container requirements for B.IP allocators Para: boost@lists.boost.org
Joaquín Mª López Muñoz wrote: [...]
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.
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&. [...]
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 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. [...]
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... ;-)
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 I think within B.IP allocator requirements lies a generic, perfectly neutral specification for (a form of) non-regular allocator support with its own merit outside the context of B.IP itself. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo