[move] [variant] Some problems with VC++10
There are some problems with VC10 libraries and move implementations in Boost,Variant and Boost.Move. The problem is that VC10 uses move() in it's STL implementation without directly specifying namespace. That leads to ambiguity, when VC10 containers are used with boost classes. I can not exactly reproduce the bug, because I have no VC at home, but thats how it looked like: std::vector< my_variant > vec; vec.push_back( my_variant(some_data) ); // ERROR: Leads to ambiguity. Compiler can not choose between std::move that is defined in the same namespace and boost::variant::detail::move(), which is found via ADL. I think, that the same thing can happen with Boost.Move library, if some class defined in namespace boost will be used in VC++ STL containers. Most generic way to get rid of such ambiguity, is to import std::move in namespace boost (if we have std::move). Best regards, Antony Polukhin
On 08/08/2011 18:54, Antony Polukhin wrote:
Most generic way to get rid of such ambiguity, is to import std::move in namespace boost (if we have std::move).
Or to get MSVC to qualify std::move. I agree it might still be a good idea to reuse std::move if it's available. The problem is that we've got no configuration macro for this. Some compilers have rvalue references but may not have a standard library that contains std::move.
[Antony Polukhin]
The problem is that VC10 uses move() in it's STL implementation without directly specifying namespace. That leads to ambiguity, when VC10 containers are used with boost classes.
[Mathias Gaunard]
Or to get MSVC to qualify std::move.
Yeah, that's a VC bug. We try to be very careful about explicitly qualifying all function calls to avoid unintentional ADL except when ADL customization is specifically desired (e.g. swap), but it's easy to screw up and not notice. I see the following offenders in VC10 SP1 with grep -dskip -P "\bmove\b" * | grep -vP "//|_STD move|_Traits::move" (yay for regexes): iterator: return (move(*current)); iterator: return (move(current[_Off])); xfwrap1: #define _A0_A1_MOV _LIST_CALL(_Arg, _Ax, move) xfwrap1: #define _F0_F1_MOV _LIST_CALL(_Farg, _Fx, move) xtr1common:#define _A1_A2_MOV_MAX _CDR2_CALL_MAX(_Arg, _Ax, move) VC11 has only: xutility: return (move(*current)); xutility: return (move(current[_Off])); in move_iterator. (We've already rewritten the fake variadic macros.) I've added _STD qualification (our internal macro for ::std::) to both lines in my current set of pending changes. (Unfortunately, I can't retroactively fix VC10, but at least I can fix the next major version.) Please let me know if you encounter any other unqualified calls that are causing trouble. My E-mail address is easy to remember. :-> Thanks, Stephan T. Lavavej Visual C++ Libraries Developer
2011/8/8 Stephan T. Lavavej <stl@exchange.microsoft.com>:
[Antony Polukhin]
The problem is that VC10 uses move() in it's STL implementation without directly specifying namespace. That leads to ambiguity, when VC10 containers are used with boost classes.
I can't retroactively fix VC10, but at least I can fix the next major version.)
It means that a workaround for VC10 is still required. Can we just make namespace boost { using std::move; } in Boost.Move and namespace boost{ namespace detail{ namespace variant { using std::move; }}} in boost/variant/detail/move.hpp for VC10 or is there some limitations? May be we shall add new preprocessor macro BOOST_NO_0X_MOVE specially for Boost.Move? Best regards, Antony Polukhin
[Antony Polukhin]
It means that a workaround for VC10 is still required. Can we just make namespace boost { using std::move; } in Boost.Move and namespace boost{ namespace detail{ namespace variant { using std::move; }}} in boost/variant/detail/move.hpp for VC10 or is there some limitations?
We do nothing squirrely in VC10 that would prevent that from working. STL
El 09/08/2011 20:23, Antony Polukhin escribió:
2011/8/8 Stephan T. Lavavej<stl@exchange.microsoft.com>:
[Antony Polukhin]
The problem is that VC10 uses move() in it's STL implementation without directly specifying namespace. That leads to ambiguity, when VC10 containers are used with boost classes.
I can't retroactively fix VC10, but at least I can fix the next major version.)
It means that a workaround for VC10 is still required. Can we just make
namespace boost { using std::move; }
I guess we should do the same for std::forward. Is VC10 move/move strictly standard conforming? This needs some tweaks in Move (what about std::move(Input, InputIt, OutIt)?). MSVC defines also move_backward but not uninitialized_move, etc. Best, Ion
participants (4)
-
Antony Polukhin -
Ion Gaztañaga -
Mathias Gaunard -
Stephan T. Lavavej