<!DOCTYPE html><html><head><meta charset="utf-8"><title>Untitled Document.md</title><style></style></head><body id="preview">
<p>LEWG, SG14: P0040R0<br>
2015-09-11<br>
Brent Friedman<br>
<a href="mailto:fourthgeek@gmail.com">fourthgeek@gmail.com</a></p>
<h1><a id="Extending_memory_management_tools_5"></a>Extending memory management tools</h1>
<h2><a id="I_Motivation_7"></a>I. Motivation</h2>
<p>When implementing containers that do not rely on standard allocators it is often necessary to manage memory directly. This paper seeks to fill gaps in the standard library’s memory management utilities.</p>
<h2><a id="II_Summary_11"></a>II. Summary</h2>
<p>The function template <code>destroy</code> calls the destructor for specified elements.<br>
The function template <code>uninitialized_move</code> performs move construction of elements over a range of memory, similar to <code>uninitialized_copy</code>. <code>uninitialized_move_n</code> is also provided.<br>
The function template <code>uninitialized_value_construct</code> performs value-construction of objects over a range of memory.<br>
The function template <code>uninitialized_default_construct</code> performs default-construction of objects over a range of memory.</p>
<h2><a id="III_Discussion_18"></a>III. Discussion</h2>
<p>Interface changes proposed in the “range” proposals should be mirrored if both are accepted.</p>
<p><code>destroy</code> first appeared in SGI’s Standard Template Library. It is not known by the author why this algorithm was not inherited into the C++ Standard Library in its initial stages. Several responses have preferred that the algorithm be called <code>destruct</code>, however, <code>destroy</code> maintains convention with SGI and appears to be considered more appropriate use of English.</p>
<p>It is not possible to implement the “no effects” policy for <code>destroy</code> so it is specifically excluded from that rule.</p>
<p>The names <code>uninitialized_value_construct</code> and <code>uninitialized_default_construct</code> explicitly reflect their effects but do not clearly match terminology in other standard library functions. Proposal N3939 has chosen the _noinit suffix to denote value vs. default construction. If LEWG prefers this direction then the algorithms could be renamed to <code>uninitialized_construct</code> and <code>uninitialized_construct_noinit</code>.</p>
<p>Some concern is raised about exception handling with respect to <code>uninitialized_move</code>. If a move-constructor throws, moved-from objects may be left in a poorly defined state. Given that algorithm <code>move</code> has no special support for this case, it is believed that throwing constructors for this algorithm can be treated similarly. It is believed that the “no effects” wording of this section is sufficient as is.<br>
An additional algorithm, <code>uninitialized_move_if_noexcept</code>, could be considered as a resolution to this concern. Given that there is currently no range-based <code>move_if_noexcept</code> algorithm, such a solution is not considered here. It is however trivial to implement such an algorithm – simply forwarding to copy or move as appropriate. The same would hold true for uninitialized algorithms.</p>
<h2><a id="IV_Proposed_Text_31"></a>IV. Proposed Text</h2>
<p>Make the following changes in [specialized.algorithm]:</p>
<p>Modify: In the algorithm&lt;u&gt;s&lt;/u&gt; uninitialized_copy &lt;u&gt;and uninitialized_move&lt;/u&gt;, the template parameter InputIterator is required…</p>
<p>Modify: In the following algorithms &lt;u&gt;other than destroy&lt;/u&gt;, if an exception is thrown there are no effects.</p>
<p>Add:</p>
<pre><code>        template&lt;class ForwardIterator&gt;
        void destroy(ForwardIterator begin, ForwardIterator end);
    
    Effects:
        typedef typename iterator_traits&lt;ForwardIterator&gt;::value_type __t;
        while (begin != end)
        {
            begin-&gt;~__t();
            ++begin;
        }
 
        
    template &lt;class InputIterator, class ForwardIterator&gt;
    ForwardIterator uninitialized_move(InputIterator first, InputIterator last, ForwardIterator result);
 
    Effects:
        for (; first != last; ++result, ++first)
            ::new (static_cast&lt;void*&gt;(addressof(*result)))
                typename iterator_traits&lt;ForwardIterator&gt;::value_type(std::move(*first));
        return result;
        
    template &lt;class InputIterator, class ForwardIterator&gt;
    ForwardIterator uninitialized_move_n(InputIterator first, size_t count, ForwardIterator result);    
    
    Effects:
        for ( ; count&gt;0; ++result, ++first, --count)
            ::new (static_cast&lt;void*&gt;(addressof(*result)))
                typename iterator_traits&lt;ForwardIterator&gt;::value_type(std::move(*first));
        return result;
    
    template&lt;class ForwardIterator&gt;
    FwdIt uninitialized_value_construct(ForwardIterator first, ForwardIterator last);
    
    Effects:
        for (; first != last; ++first)
            ::new (static_cast&lt;void*&gt;(addressof(*first)))
                typename iterator_traits&lt;ForwardIterator&gt;::value_type();
        return first;
    
    template&lt;class ForwardIterator&gt;
    FwdIt uninitialized_default_construct(ForwardIterator first, ForwardIterator last);
    
    Effects:
        for (; first != last; ++first)
            ::new (static_cast&lt;void*&gt;(addressof(*first)))
                typename iterator_traits&lt;ForwardIterator&gt;::value_type;
        return first;</code></pre>

</body></html>
