Boost logo

Boost Users :

Subject: Re: [Boost-users] [Boost.Move] Conflict between std::move and boost::move (Boost 1.49.0)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-07-10 17:49:05


Le 10/07/12 23:18, Jonathan Jones a écrit :
> Hi folks,
>
> Consider the following code (which distilled from a real world example):
>
>
> #include <boost/move/move.hpp>
> #include <boost/optional/optional.hpp>
> #include <utility>
> #include <vector>
>
> typedef boost::optional<int> data_type;
> typedef std::vector<data_type> vector_type;
>
> vector_type func()
> {
> vector_type vv;
> return move(vv);
> }
>
>
> If I compile this code using Boost 1.49 on Visual Studio 2010, or on a
> recent version of g++ (e.g. 4.7.1) which supports some C++11 features,
> the code fails to compile, complaining about ambiguity between
> std::move and boost::move. Strangely, the code compiles fine with
> Apple Clang version 3.1.
Which compiler has the correct behavior?

> Is there a way to work around the compilation problem which doesn't
> involve explicitly qualifying the calls to move? I'd prefer to use
> argument-dependent-lookup. Removing the includes of boost/move.hpp is
> not possible. In the real world example, that header is included
> indirectly.
>
> I did notice that if I define the macro
> BOOST_MOVE_USE_STANDARD_LIBRARY_MOVE, the compilation errors
> disappear. Is this the correct approach for compilers which support
> std::move? I find it odd that this macro isn't already defined for
> such compilers.
>
>
It seems you have found the solution. Could you create a ticket so that
macro is defined when the std library provides std::move? In the
meantime you could define the macro yourself.

Best,
Vicente



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net