title: The move function in unique_ptr C++03 emulation
body: <p>I'm trying to understand how <a href="http://home.roadrunner.com/~hinnant/unique_ptr03.html" rel="nofollow">C++03 emulation of unique_ptr</a> is implemented. unique_ptr is quite like std::auto_ptr but safer. It spits out compiler errors in cases where auto_ptr would have transferred ownership implicitly (i.e., silently). For example, a simple assignment. Function <code>move</code> is the key behind emulated unique_ptr's safety. </p>
  
  <p>Questions:</p>
  
  <ol>
  <li>Why are there three move functions?</li>
  <li><p>The third move function that accepts a reference and turns it into an rvalue, is implemented (simplified) as follows. </p>
  
  <pre><code>T move(T &amp;t) { 
    return T(detail_unique_ptr::rv&lt;T&gt;(t)); 
  }
  </code></pre></li>
  </ol>
  
  <p>In the above code, an explicit conversion to T seems kind of unnecessary. In fact, Visual Studio 2010 is perfectly happy without an explicit conversion to T. </p>
  
  <pre><code>T move(T &amp;t) {
    return detail_unique_ptr::rv&lt;T&gt;(t);
  }
  </code></pre>
  
  <p>g++, clang, Comeau, however, do not like the second version. These compilers complain that there is no constructor for <code>unique_ptr&lt;T&gt;</code> that takes <code>detail_unique_ptr::rv&lt;T&gt;</code> as a parameter. Why is that? unique_ptr already defines a (non-explicit) constructor that takes <code>detail_unique_ptr::rv&lt;T&gt;</code> as a parameter. Why isn't that one picked up automatically?</p>