<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 582: specialized algorithms and volatile storage</title>
<meta property="og:title" content="Issue 582: specialized algorithms and volatile storage">
<meta property="og:description" content="C++ library issue. Status: NAD">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue582.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#NAD">NAD</a> status.</em></p>
<h3 id="582"><a href="lwg-closed.html#582">582</a>. specialized algorithms and volatile storage</h3>
<p><b>Section:</b> 26.11.5 <a href="https://wg21.link/uninitialized.copy">[uninitialized.copy]</a> <b>Status:</b> <a href="lwg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-14 <b>Last modified:</b> 2016-01-28</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#uninitialized.copy">issues</a> in [uninitialized.copy].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>

<p>Related to <a href="lwg-closed.html#1029" title="Specialized algorithms for memory management need to be concept-constrained templates (Status: NAD Concepts)">1029</a><sup><a href="https://cplusplus.github.io/LWG/issue1029" title="Latest snapshot">(i)</a></sup></p>
        <p>

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

        </p>
            <pre>

new (static_cast&lt;void*&gt;(&amp;*i))
    typename iterator_traits&lt;ForwardIterator&gt;::value_type (x)

            </pre>
        <p>

This  expression is  ill-formed  when the  type  of the  subexpression
<code>&amp;*i</code> is some volatile-qualified <code>T</code>.

        </p>

<p><i>[
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.
]</i></p>



<p><i>[
2009-06-17 Pablo adds:
]</i></p>


<blockquote>

<p>Propose that Issue <a href="lwg-closed.html#582" title="specialized algorithms and volatile storage (Status: NAD)">582</a><sup><a href="https://cplusplus.github.io/LWG/issue582" title="Latest snapshot">(i)</a></sup> be closed NAD.</p>
<p>
Issue <a href="lwg-closed.html#582" title="specialized algorithms and volatile storage (Status: NAD)">582</a><sup><a href="https://cplusplus.github.io/LWG/issue582" title="Latest snapshot">(i)</a></sup> asks that <code>uninitialized_copy</code>,
<code>uninitialized_fill</code>, and <code>uninitialized_fill_n</code> 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 <code>uninitialized_copy</code> on volatile storage is not useful. A
possible editorial change would be to put my previous sentence into a
non-normative note.
</p>
<p>
Note that the three sections starting with 26.11.5 <a href="https://wg21.link/uninitialized.copy">[uninitialized.copy]</a> do not
yet have concepts.  Here's a first crack at the first one:
</p>
<blockquote><pre>
template &lt;InputIterator InIter, OutputIterator OutIter&gt;
requires ExplicitConvertible&lt;HasDereference&lt;OutIter::reference&gt;::result,
                             OutIter::value_type&amp;&gt;
      &amp;&amp; Convertible&lt;OutIter::value_type*, void*&gt;
      &amp;&amp; ExplicitConvertible&lt;OutIter::value_type, InIter::reference&gt;
  OutIter uninitialized_copy(InIter first, InIter last, OutIter result);
</pre>
<blockquote>
<p>
Effects:
</p>
<blockquote><pre>
while (first != last) {
  typedef OutIter::value_type value_type;
  value_type&amp; outRef = static_cast&lt;value_type&amp;&gt;(*result++);
  ::new (static_cast&lt;void*&gt;(addressof(outRef))) value_type(*first++);
}
</pre></blockquote>
</blockquote>

</blockquote>

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

</blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
<p>
We don't deal with volatile in the library.
</p>
<p>
Jim: should we state that explicitly somewhere?
</p>
<p>
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.
</p>
<p>
Hinnant: actually, some library components do handle volatile, so we'd
need to be very careful about what we say in clause 17.
</p>
<p>
No objection to NAD.
</p>
<p>
Move to NAD.
</p>
</blockquote>

    

    <p id="res-582"><b>Proposed resolution:</b></p>
        <p>

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:

        </p>
            <pre>

<i>Effects</i>:

typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;

for (; first != last; ++result, ++first)
    new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*result))
        value_type (*first);

            </pre>
        <p>

change 20.6.4.2, p1 to read

        </p>
            <pre>

<i>Effects</i>:

typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;

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

            </pre>
        <p>

and change 20.6.4.3, p1 to read

        </p>
            <pre>

<i>Effects</i>:

typedef typename iterator_traits&lt;ForwardIterator&gt;::pointer    pointer;
typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type value_type;

for (; n--; ++first)
    new (static_cast&lt;void*&gt;(const_cast&lt;pointer&gt;(&amp;*first))
        value_type (*x);

            </pre>
        <p>

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

        </p>
        <p>

and for pointers to volatile as 

        </p>
            <pre>

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

            </pre>
        <p>

Note that  the change to  <code>iterator_traits</code> 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 <code>iterator_traits</code> as
is  done here.   Implementations can  (and some  do) achieve  the same
effect by means of function template overloading.

        </p>
    



</body>
</html>
