[Boost-commit] svn:boost r51928 - sandbox/committee/rvalue_ref

Subject: [Boost-commit] svn:boost r51928 - sandbox/committee/rvalue_ref
From: dave_at_[hidden]
Date: 2009-03-23 00:52:46

Author: dave
Date: 2009-03-23 00:52:43 EDT (Mon, 23 Mar 2009)
New Revision: 51928
URL: http://svn.boost.org/trac/boost/changeset/51928

Log:
Wrote up a review of Move Semantics Idioms

Text files modified: 
   sandbox/committee/rvalue_ref/nothrowmove.org                  |     1                                         
   sandbox/committee/rvalue_ref/rvalue-ref-exception-safety.html |    60 +++++++++++++++++++++++++++++++++++++++ 
   2 files changed, 60 insertions(+), 1 deletions(-)

Modified: sandbox/committee/rvalue_ref/nothrowmove.org
==============================================================================
--- sandbox/committee/rvalue_ref/nothrowmove.org	(original)
+++ sandbox/committee/rvalue_ref/nothrowmove.org	2009-03-23 00:52:43 EDT (Mon, 23 Mar 2009)
@@ -7,6 +7,7 @@
    [2009-03-21 Sat]
 *** TODO Look through all move ctors for need to handle like pair.
    [2009-03-21 Sat]
+*** TODO Dave read through HTML doc
 ** Notes
 * Incidental Issues
 ** Tasks

Modified: sandbox/committee/rvalue_ref/rvalue-ref-exception-safety.html
==============================================================================
--- sandbox/committee/rvalue_ref/rvalue-ref-exception-safety.html	(original)
+++ sandbox/committee/rvalue_ref/rvalue-ref-exception-safety.html	2009-03-23 00:52:43 EDT (Mon, 23 Mar 2009)
@@ -103,6 +103,64 @@
 strong exception guarantee, such as <code>push_back</code>
 (23.1.1p10).</p>
 
+<h2 id="review">Review of Move Semantics Idioms</h2>
+
+The most common "move constructor" signature for a type <code>T</code>
+is <code>T(T&&)</code>, but <em>every</em> move constructor:
+<ol>
+  <li>Can be called with a single non-const rvalue argument of type <code>T</code></li>
+  <li>Has a non-const reference parameter to which that rvalue is bound
+  <li>Transfers resources from that rvalue into the newly-constructed object
+    </ol>
+Although move construction modifies its argument by transferring
+resources away from it, move construction from a real rvalue is still
+a "logically non-mutating" operation.  Since the move constructor
+holds the only reference to that rvalue, any modifications are
+invisible to the rest of the program.  These invisible move
+constructions can take effect automatically whenever an rvalue may
+need to be copied, for example when an rvalue argument is passed by
+value.
+
+However, move construction can also be <em>explicitly requested</em>
+for lvalue arguments.  The standard idiom
+is <code>T(std::move(x))</code>, where <code>x</code> is an lvalue of
+type <code>T</code>.  The <code>std::move</code> function template
+simply casts its lvalue argument to the corresponding rvalue type:
+
+<pre>
+template <class T>
+T&& move(T& x) { return static_cast<T&&>(x); }
+</pre>
+  
+The <code>T(std::move(x))</code> idiom is only a move <em>request</em>
+because in general, <code>T</code> may not have a move constructor, in
+which case an available copy constructor will be used instead.  Such
+an explicit move request can be used anytime a function knows that a
+particular value is no longer needed.  The simplest example is
+in <code>std::swap</code>:
+
+<pre>
+template <class T>
+void swap(T& x, T& y)
+{
+   T tmp(std::move(x));  // 1
+   x = std::move(y);     // 2
+   y = std::move(tmp);   // 3
+}
+</pre>
+
+In this case, it is safe to move from <code>x</code> in line 1 because
+we are about to assign into <code>x</code> in line 2.
+Since <em>copying</em> <code>x</code> is also an acceptable (though
+sometimes suboptimal) way to transfer its value into <code>tmp</code>,
+this code still works when <code>T</code> has a copy constructor but
+no move constructor.  
+
+The act of constructing a new <code>T</code> from an
+explicitly-generated <code>T&&</code> bound to an lvalue is known in
+this paper as "the move operation," whether it actually ends up moving
+or falls back to invoking a copy constructor.
+
 <h2 id="problem">The Problem</h2>
 
 <p>The problem addressed by this paper is three-fold.  First, under
@@ -285,7 +343,7 @@
 committed to only using operations that can no longer throw, such as
 deallocating memory or destroying already-constructed objects.</p>
 
-<p>The problem with a throwing move operation is that it fits into
+<p>The problem with a throwing move constructor is that it fits into
 both partitions. It can throw exceptions (obviously) and it is also a
 non-reversible modification, because (1) moving is permitted to
 transfer resources and (2) there is no non-throwing operation to