On Tue, Jul 21, 2015 at 5:43 PM, Eric Fiselier <e...@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 <rich...@metafoo.co.uk> > wrote: > > On Tue, Jul 21, 2015 at 5:29 PM, Eric Fiselier <e...@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. >
_______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits