[PATCH] D11394: Fix warnings about pessimizing return moves for C++11 and higher

[Eric Fiselier]

> I don't think that's right. In C++03, unique_ptr has a unique_ptr(unique_ptr&) constructor. And the C++03 std::move is:
>
>  template<typename T> T &move(T &v) { return v; }
>
> So... the "explicitly moved for C++03" call to std::move in map appears to also be redundant (and pessimizing) in C++03. In fact, in C++03, std::move > appears to *always* be a no-op.

I don't think unique_ptr provides the constructor you mention. The
definition of move used in C++03 for unique_ptr is

 unique_ptr move(unique_ptr& u) {
    return unique_ptr(__rv<unique_ptr>(u));
  }

unique_ptr provides a constructor of the form `unique_ptr(__rv<unique_ptr>&).

It seems like this dance is done to force copy elision to take place.

/Eric


On Tue, Jul 21, 2015 at 8:35 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Tue, Jul 21, 2015 at 5:29 PM, Eric Fiselier <eric at efcs.ca> wrote:
>>
>> EricWF added a comment.
>>
>> Thanks for the patch. I ran into this issue the other day and I'm glad to
>> see it fixed.
>>
>> A little rational: The explicit move's are needed in order to "move" a
>> `unique_ptr` in C++03. There is a special definition of `std::move` in
>> memory at line 3100 that performs some hacks to make `unique_ptr` movable. I
>> don't think any other classes benefit from the "explicit move" in C++03.
>
>
> I don't think that's right. In C++03, unique_ptr has a
> unique_ptr(unique_ptr&) constructor. And the C++03 std::move is:
>
>   template<typename T> T &move(T &v) { return v; }
>
> So... the "explicitly moved for C++03" call to std::move in map appears to
> also be redundant (and pessimizing) in C++03. In fact, in C++03, std::move
> appears to *always* be a no-op.