Compilation error when boost.thread and boost.move are used together

[admin@…]

Thread component has the definition "move" in boost/thread/detail/move.hpp, but new version of library contains the global description of "move" semantics in boost.move. It gives the conflict at compilation "ambiguous call to overloaded function". It is a code reproduces the given problem.

#include <boost/thread.hpp>
#include <boost/move/move.hpp>

void func()
{
    boost::shared_mutex mutex;
    boost::upgrade_lock<boost::shared_mutex>           _upgrade_lock(mutex);
    boost::upgrade_to_unique_lock<boost::shared_mutex> _unique_lock(_upgrade_lock); // compilation error
}

[anonymous]

Looks like I have the same problem (boost 1.48, MSVC2008):

enc_frame_queue.cpp:74: error: C2664: 'boost::upgrade_to_unique_lock<Mutex>::upgrade_to_unique_lock(boost::upgrade_to_unique_lock<Mutex> &)' : cannot convert parameter 1 from 'boost::shared_lock<Mutex>' to 'boost::upgrade_to_unique_lock<Mutex> &' with [

Mutex=boost::shared_mutex

]

[anonymous]

Yes, same issue here.

[blake-r@…]

--- a/locks.hpp	2011-12-05 12:26:11.650309054 +0400
+++ b/locks.hpp	2011-12-05 12:27:25.905311415 +0400
@@ -923,13 +923,13 @@
         upgrade_to_unique_lock& operator=(upgrade_to_unique_lock&);
     public:
         explicit upgrade_to_unique_lock(upgrade_lock<Mutex>& m_):
-            source(&m_),exclusive(move(*source))
+            source(&m_),exclusive(move(detail::thread_move_t<upgrade_lock<Mutex> >(*source)))
         {}
         ~upgrade_to_unique_lock()
         {
             if(source)
             {
-                *source=move(exclusive);
+                *source=move(detail::thread_move_t<unique_lock<Mutex> >(exclusive));
             }
         }
 

[viboes]

The is an action point to use Boost.Move. Could we consider this as a duplicate of #6194 Adapt to Boost.Move.

[anonymous]

That's fine if you want to fix it when addressing #6194 - but this bug is actually a regression...code that used to work in 1.47.0 no longer even compiles in 1.48.0. It prevents you from using boost/thread/locks.hpp in conjunction with boost/unordered_map.hpp - since unordered map uses Boost::Move and thread locks use the other Boost::Move.

[anonymous]

In other words, I think this issue should actually be "upgraded" to a regression - instead of "downgraded" to a feature request (which #6194 is...)

[viboes]

The following patch in boost/move/move.hpp allows to avoid the issue provided Boost.Thread adds the needed specializations for has_move_emulation_enabled_aux.

 svn diff
Index: move.hpp
===================================================================
--- move.hpp	(revision 75884)
+++ move.hpp	(working copy)
@@ -280,6 +280,10 @@
       : BOOST_MOVE_BOOST_NS::integral_constant<bool, false>
    {};
 
+   template <class T>
+   struct has_move_emulation_enabled_aux 
+     : has_move_emulation_enabled<T> {};
+     
    template <class T> 
    struct has_nothrow_move
       : public BOOST_MOVE_BOOST_NS::integral_constant<bool, false>
@@ -290,8 +294,9 @@
    //                            move()
    //
    //////////////////////////////////////////////////////////////////////////////
+    
    template <class T>
-   typename BOOST_MOVE_BOOST_NS::disable_if<has_move_emulation_enabled<T>, T&>::type move(T& x)
+   typename BOOST_MOVE_BOOST_NS::disable_if<has_move_emulation_enabled_aux<T>, T&>::type move(T& x)
    {
       return x;
    }

Waiting for Ion response to see if he accepts this patch.

[viboes]

Boost.Move patch committed

svn ci move.hpp -m "Move/Thread: Added type tait so that #6141 - Compilation error when boost.thread and boost.move are used together - can be solved on the Boost.Thread side"

Sending move.hpp Transmitting file data . Committed revision #76271.

[viboes]

Committed in trunk at revision #76277 Boost.Thread part.

[viboes]

(In [76346]) Thread: merge from trunk to fix #6141, #5594, #5040 and #5502.