From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2007-06-04 18:19:51
----- Mensaje original -----
De: Ion Gaztañaga <igaztanaga_at_[hidden]>
Fecha: Lunes, Junio 4, 2007 9:17 pm
Asunto: Re: [boost] [interprocess] container requirements for B.IP
> 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
> 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
typedef my_smart_pointer<T> pointer;
// out of malevolence I specialize as follows
// same interface as my_smart_pointer<char>
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk