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

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 
allocators
Para: boost_at_[hidden]

> 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