C++17 expression evaluation order and std::move
<p>Whilst refactoring some code today to change raw pointers to <code>std::unique_ptr</code>, I encountered a segmentation fault due to an <a href="http://en.cppreference.com/w/cpp/language/eval_order" rel="noreferrer"><em>order of evaluation</em></a> bug.</p>

<p>The old code did something like the following:</p>

<pre><code>void add(const std::string&amp; name, Foo* f)
{
    _foo_map[name] = f;
}

void process(Foo* f)
{
    add(f-&gt;name, f);
}
</code></pre>

<p>The first, naive, refactoring of the code to use <code>std::unique_ptr</code>:</p>

<pre><code>void add(const std::string&amp; name, std::unique_ptr&lt;Foo&gt; f)
{
    _foo_map[name] = std::move(f);
}

void process(std::unique_ptr&lt;Foo&gt; f)
{
    add(f-&gt;name, std::move(f)); // segmentation-fault on f-&gt;name
}
</code></pre>

<p>The refactored code causes a segmentation fault, because the 2nd argument (<code>std::move(f)</code>) is processed first, and then the 1st argument (<code>f-&gt;name</code>) dereferences a moved-from variable, boom!</p>

<p>Possible fixes to this are to obtain a handle on <code>Foo::name</code> <em>before</em> moving it in the call to <code>add</code>:</p>

<pre><code>void process(std::unique_ptr&lt;Foo&gt; f)
{
    const std::string&amp; name = f-&gt;name;
    add(name, std::move(f));
}
</code></pre>

<p>Or perhaps:</p>

<pre><code>void process(std::unique_ptr&lt;Foo&gt; f)
{
    Foo* fp = f.get();
    add(fp-&gt;name, std::move(f));
}
</code></pre>

<p>Both of these solutions require extra lines of code, and don't seem nearly as composable as the original (albeit UB) call to <code>add</code>.</p>

<p><strong>Questions:</strong></p>

<ul>
<li><p>Are either of the 2 proposed solutions above <em>idiomatic</em> C++, and if not, is there a better alternative?</p></li>
<li><p>I see there are changes comingi n C++17 due to  <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r3.pdf" rel="noreferrer">P0145R3 - Refining Expression Evaluation Order for
Idiomatic C++</a>. Will this change any of the above solutions / prevent their pitfalls?</p></li>
</ul>