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 am not completely satisfied with the macro name (I also considered
> _LIBCPP_COMPAT_MOVE and some other variants), so suggestions are
> welcome. :)
I think the name is fine and there is no need to change it. However maybe the
name should reflect the fact that it is only needed for `unique_ptr`? Something
like `_LIBCPP_UNIQUE_PTR_MOVE` would better convey the weirdness this macro is
doing.
================
Comment at: include/__config:719
@@ -718,1 +718,3 @@
+#if _LIBCPP_STD_VER < 11
+# define _LIBCPP_EXPLICIT_MOVE(x) _VSTD::move(x)
----------------
We need the explicit move whenever `_LIBCPP_HAS_NO_RVALUE_REFERENCES` is
defined. Please use that instead.
================
Comment at: include/algorithm:854
@@ -853,3 +853,3 @@
__f(*__first);
- return _VSTD::move(__f); // explicitly moved for (emulated) C++03
+ return _LIBCPP_EXPLICIT_MOVE(__f); // explicitly moved for (emulated)
C++03
}
----------------
This one seems suspect. I don't really know if we need the move here. Do you
know why this here?
http://reviews.llvm.org/D11394
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
