title: creating a shared_ptr from unique_ptr
body: <p>In a piece of code I reviewed lately, which compiled fine with <code>g++-4.6</code>, I encountered a strange try to create a <code>std::shared_ptr</code> from <code>std::unique_ptr</code>:</p>
  
  <pre><code>std::unique_ptr&lt;Foo&gt; foo...
  std::make_shared&lt;Foo&gt;(std::move(foo));
  </code></pre>
  
  <p>This seems rather odd to me. This should be <code>std::shared_ptr&lt;Foo&gt;(std::move(foo));</code> afaik, though I'm not perfectly familiar with moves (and I know <code>std::move</code> is only a cast, nothing get's moved).</p>
  
  <p>Checking with different compilers on this SSC(NUC*)E</p>
  
  <pre><code>#include &lt;memory&gt;
  
  int main()
  {
     std::unique_ptr&lt;int&gt; foo(new int);
     std::make_shared&lt;int&gt;(std::move(foo));
  }
  </code></pre>
  
  <p>Results of compilation:</p>
  
  <ul>
  <li>g++-4.4.7     gives compilation error</li>
  <li>g++-4.6.4     compiles without any error</li>
  <li>g++-4.7.3     gives <strong>internal compiler error</strong></li>
  <li>g++-4.8.1     gives compilation error</li>
  <li>clang++-3.2.1 compiles without any error</li>
  </ul>
  
  <p>So the question is: which compiler is right in terms of the standard? Does the standard require this to be an invalid statement, a valid statement or is this simply undefined?</p>
  
  <p><strong>Addition</strong></p>
  
  <p>We've agreed on that some of these compilers, such as clang++ and g++-4.6.4, permit the conversion while they shouldn't. However with g++-4.7.3 (which produces an internal compiler error on <code>std::make_shared&lt;Foo&gt;(std::move(foo));</code>), correctly rejects <code>int bar(std::move(foo));</code> </p>
  
  <p>Because of this huge difference in behavior, I'm leaving the question as it is, although part of it would be answerable with the reduction to <code>int bar(std::move(foo));</code>. </p>
  
  <hr>
  
  <p>*) NUC: Not universally compilable</p>