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

Richard Smith richard at metafoo.co.uk
Tue Jul 21 18:17:13 PDT 2015


On Tue, Jul 21, 2015 at 5:43 PM, Eric Fiselier <eric at efcs.ca> wrote:

> > 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.


Well, it does (memory:2554), but it's private. Sorry, I didn't notice that
before...

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.
>

It looks like libc++'s design for unique_ptr means that it's not possible
to get NRVO to apply to it in C++03. The approach in this patch seems fine
to me.


> /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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150721/4bb195f3/attachment.html>


More information about the cfe-commits mailing list