This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

582. specialized algorithms and volatile storage

Section: 26.11.5 [uninitialized.copy] Status: NAD Submitter: Martin Sebor Opened: 2006-06-14 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [uninitialized.copy].

View all issues with NAD status.

Discussion:

Related to 1029⁽ⁱ⁾

The specialized algorithms [lib.specialized.algorithms] are specified as having the general effect of invoking the following expression:

new (static_cast<void*>(&*i))
    typename iterator_traits<ForwardIterator>::value_type (x)

            

This expression is ill-formed when the type of the subexpression &*i is some volatile-qualified T.

[ Batavia: Lack of support for proposed resolution but agree there is a defect. Howard to look at wording. Concern that move semantics properly expressed if iterator returns rvalue. ]

[ 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 26.11.5 [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.

[ 2009-07 Frankfurt ]

We don't deal with volatile in the library.

Jim: should we state that explicitly somewhere?

Beman: you might argue that clause 17 should say something about volatile. However, if you want to raise we argument, we should open it as a separate issue and consult with experts on concurrency.

Hinnant: actually, some library components do handle volatile, so we'd need to be very careful about what we say in clause 17.

No objection to NAD.

Move to NAD.

Proposed resolution:

In order to allow these algorithms to operate on volatile storage I propose to change the expression so as to make it well-formed even for pointers to volatile types. Specifically, I propose the following changes to clauses 20 and 24. Change 20.6.4.1, p1 to read:

Effects:

typedef typename iterator_traits<ForwardIterator>::pointer    pointer;
typedef typename iterator_traits<ForwardIterator>::value_type value_type;

for (; first != last; ++result, ++first)
    new (static_cast<void*>(const_cast<pointer>(&*result))
        value_type (*first);

            

change 20.6.4.2, p1 to read

Effects:

typedef typename iterator_traits<ForwardIterator>::pointer    pointer;
typedef typename iterator_traits<ForwardIterator>::value_type value_type;

for (; first != last; ++result, ++first)
    new (static_cast<void*>(const_cast<pointer>(&*first))
        value_type (*x);

            

and change 20.6.4.3, p1 to read

Effects:

typedef typename iterator_traits<ForwardIterator>::pointer    pointer;
typedef typename iterator_traits<ForwardIterator>::value_type value_type;

for (; n--; ++first)
    new (static_cast<void*>(const_cast<pointer>(&*first))
        value_type (*x);

            

In addition, since there is no partial specialization for iterator_traits<volatile T*> I propose to add one to parallel such specialization for <const T*>. Specifically, I propose to add the following text to the end of 24.3.1, p3:

and for pointers to volatile as

namespace std {
template<class T> struct iterator_traits<volatile T*> {
typedef ptrdiff_t difference_type;
typedef T value_type;
typedef volatile T* pointer;
typedef volatile T& reference;
typedef random_access_iterator_tag iterator_category;
};
}

            

Note that the change to iterator_traits isn't necessary in order to implement the specialized algorithms in a way that allows them to operate on volatile strorage. It is only necesassary in order to specify their effects in terms of iterator_traits as is done here. Implementations can (and some do) achieve the same effect by means of function template overloading.