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 cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits