Boost C++ Libraries: Ticket #6141: Compilation error when boost.thread and boost.move are used together

cc set

nathan@… — Fri, 02 Dec 2011 21:03:11 GMT

cc nathan@… added

anonymous — Fri, 02 Dec 2011 22:59:55 GMT

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 — Mon, 05 Dec 2011 08:16:10 GMT

Yes, same issue here.

blake-r@… — Mon, 05 Dec 2011 08:29:30 GMT

--- 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));
             }
         }

cc changed; keywords set

viboes — Sun, 11 Dec 2011 11:40:41 GMT

cc viboes added
keywords move added

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

anonymous — Mon, 12 Dec 2011 00:41:18 GMT

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 — Mon, 12 Dec 2011 00:43:50 GMT

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

severity changed

Hartmut Kaiser — Sun, 01 Jan 2012 22:06:23 GMT

severity Problem → Showstopper

milestone changed

Hartmut Kaiser — Sun, 01 Jan 2012 22:07:52 GMT

milestone To Be Determined → Boost 1.49.0

viboes — Mon, 02 Jan 2012 02:47:10 GMT

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 — Mon, 02 Jan 2012 12:17:34 GMT

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 — Mon, 02 Jan 2012 17:14:40 GMT

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

owner, status changed

viboes — Tue, 03 Jan 2012 18:15:07 GMT

owner changed from Anthony Williams to viboes
status new → assigned

status changed; resolution set

viboes — Sat, 07 Jan 2012 20:53:02 GMT

status assigned → closed
resolution → fixed

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