N2257 proposes removing allocators' construct(), destroy() and address
() member functions, on the grounds that their existence impedes some
useful extension like in-place construction of container elements. I
understand how construct() blocks these kind of extensions, but I fail
to
see why address()  should also go away. IMHO, dropping address() is
too
drastic and reduces immensely the type of special allocators
implementations could deal with: for  example, consider the following
non-standard allocator with non-equal instances  where ::pointer is
some
kind of offset to an internal data structure:

template<typename T>
class special_allocator
{
  ...
  class offset
  {
    // random access pointer interface
    ...
  private:
    T*       base_ptr;
    size_t off;
  };
  typedef offset pointer;
  ...

  pointer address(T& t)
  {
    return offset(buff,&t-buff);
  }

private:
  T* buff;
};

Obviously, special_allocator::address() is needed here since it's not
possible to go from T& to special_allocator::pointer without relating
the
procedure to a particular allocator instance. construct() and
destroy()
aren't  really needed for this special type of allocator, though:

// construct a copy of t on the special_allocator<T>::pointer p
new((void*)(&(*p))T(t);

// destroy the contents of the special_allocator<T>::pointer p
&(*p)->~T();

(boost::addressof can be used in place of & if pointer::operator& is
permitted to be overloaded.)

As for open LWG issues related to these member functions (401, 580,
634
and 635),  the only two specifically related to address() are 634 and
635:

* 634: This issue deals only with the particular behavior of
std::allocator::address(), so it does not really interact with
lib.allocator.requirements, which is the topic of this post.

* 635: The problem posed by this issue is that restricting address
retrieval only to values allocated by the container instance upon
which
address() is invoked is too restrictive and may make things hard for
code
such as that of list::remove(const T& t) where the address of t might
need
to be compared with those of the elements of the list. In my opinion,
this
issue is not really a showstopper, since address comparison of t with
some element q of the list can be done without resorting to address():

  boost::adddressof(t)==boost::addressof(q)

We're comparing actual addresses rather than allocator::pointer's,
but
this is immaterial in the context of the problem described by the
issue.

So, to sum it up, my opinion is that allocators' address() member
function should be retained as part of the interface because:

1. It allows for special types of non-standard allocators to be
supported by the implementations.
2. It does not clash with any envisioned functionality extension such
as in-place element construction via variadic templates.
3. Pending issues related to address() can be solved without resorting
to eliminating this member function.

Thank you,

Joaqu   n M L   pez Mu   oz
Telef   nica, Investigaci   n y Desarrollo


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]