Date
2009-06-17.00:00:00
Message id
3131

Content

[ 2009-06-17 Pablo adds: ]

Propose that Issue 582 be closed NAD.

Issue 582 asks that uninitialized_copy, uninitialized_fill, and uninitialized_fill_n should be well-formed if the result type is volatile. My feeling is that the standard does not, and should not, guarantee any useful behavior when constructors are invoked on volatile storage, so making it syntactically legal to call uninitialized_copy on volatile storage is not useful. A possible editorial change would be to put my previous sentence into a non-normative note.

Note that the three sections starting with [uninitialized.copy] do not yet have concepts. Here's a first crack at the first one:

template <InputIterator InIter, OutputIterator OutIter>
requires ExplicitConvertible<HasDereference<OutIter::reference>::result,
                             OutIter::value_type&>
      && Convertible<OutIter::value_type*, void*>
      && ExplicitConvertible<OutIter::value_type, InIter::reference>
  OutIter uninitialized_copy(InIter first, InIter last, OutIter result);

Effects:

while (first != last) {
  typedef OutIter::value_type value_type;
  value_type& outRef = static_cast<value_type&>(*result++);
  ::new (static_cast<void*>(addressof(outRef))) value_type(*first++);
}

Notes:

  1. This definition is actually LESS constrained than in C++03 because there is no requirement that the result be a forward iterator.
  2. If OutIter returns a proxy type with an overloaded operator&, this definition probably won't compile. Lifting this limitation while allowing value_type to have an overloaded operator& would be hard, but is probably possible with careful overloading. I'm not sure it's worth it.
  3. This definition retains the prohibition on the use of volatile types for the result.