|
Boost : |
Subject: Re: [boost] [thread] Boost.Thread defines boost::move which conflicts with Boost.Move
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-01-01 17:25:24
Le 01/01/12 20:53, Eric Niebler a écrit :
> On 1/1/2012 11:16 AM, Hartmut Kaiser wrote:
>>> On 12/31/2011 1:58 PM, Hartmut Kaiser wrote:
>>>> VC10, SVN trunk:
>>>>
>>>> #include<boost/move/move.hpp>
>>>> #include<boost/thread.hpp>
>>>>
>>>> int main()
>>>> {
>>>> return 0;
>>>> }
>>>>
>>>> Results in:
>>>>
>>>> .../boost/thread/detail/move.hpp(28) : error C2995:
>>>> 'remove_reference<T>::type&&boost::move(T&&)' : function template
>>>> has already been defined .../boost/move/move.hpp(466) : see
>>>> declaration of 'boost::move'
>>>>
>>>> IMHO, Boost.Thread needs to be changed to rely on Boost.Move for move
>>>> semantics instead of defining its own implementation for boost::move().
>>> That sounds serious. Hartmut, can you file a showstopper for 1.50 so this
>>> doesn't get lost?
>> I already filed it: #6341. However, shouldn't it be a show stopper for 1.49?
> Ah. You said trunk. Does this also happen on release? If so, yes, this
> should be a showstopper for 1.49.
>
Hi,
this was already identified one month ago (see Boost.Thread and
Boost.Move collision
http://boost.2283326.n4.nabble.com/Boost-Thread-and-Boost-Move-collision-tt4127995.html).
This was introduced in 1.48 when Boost.Move was released.
From the option Ion presented the option to adapt Boost.Thread to use
Boost.Move was the more convenient. Unfortunately this will need some
time. Mankarse said that is working on it, but for the moment we don't
have a path ready.
I proposed a temporary solution " What I purpose for the short term
(1.49) is to let the user to choose the namespace for the move function
(by default Boost.Thread will use boost::), and the user could state
that it should use boost::thread:: instead. ", but nobody supported it.
With this possibility, Boost.Move could force the namespace to
boost::thread.
<http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=user_nodes&user=267900>Mankarse
do you a have a patch ready?
I could try to implement the temporary workaround which should be less
risky.
Best,
Vicente
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk