[thread][config] VC10RC fails compiling when using thread library (BOOST_NO_RVALUE_REFERENCES)
Hey all, the new 'un-definition' of BOOST_NO_RVALUE_REFERENCES for VC10 breaks compilation of code using the thread library. Is it a problem of VC10 or the thread library? Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com
"Hartmut Kaiser" <hartmut.kaiser@gmail.com> writes:
the new 'un-definition' of BOOST_NO_RVALUE_REFERENCES for VC10 breaks compilation of code using the thread library. Is it a problem of VC10 or the thread library?
It's a bug in VC10. I've reported it to MS, see the link below. It's unlikely to be fixed before VC10 ships. https://connect.microsoft.com/VisualStudio/feedback/details/525239/binding-o... Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
the new 'un-definition' of BOOST_NO_RVALUE_REFERENCES for VC10 breaks compilation of code using the thread library. Is it a problem of VC10 or the thread library?
It's a bug in VC10. I've reported it to MS, see the link below. It's unlikely to be fixed before VC10 ships.
https://connect.microsoft.com/VisualStudio/feedback/details/525239/bind ing-of-function-pointer-to-rvalue-reference-in-templated-constructor- fails
I guess we should re-define BOOST_NO_RVALUE_REFERENCES for VC10, then, no? Who is maintaining the config files for MSVC? Beman? Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com
It would be nice for them to be available in situations that arent affected by this bug. Is there a workaround that can be applied for this one case? On Feb 17, 2010, at 6:12 PM, "Hartmut Kaiser" <hartmut.kaiser@gmail.com> wrote:
the new 'un-definition' of BOOST_NO_RVALUE_REFERENCES for VC10 breaks compilation of code using the thread library. Is it a problem of VC10 or the thread library?
It's a bug in VC10. I've reported it to MS, see the link below. It's unlikely to be fixed before VC10 ships.
https://connect.microsoft.com/VisualStudio/feedback/details/525239/bind ing-of-function-pointer-to-rvalue-reference-in-templated-constructor- fails
I guess we should re-define BOOST_NO_RVALUE_REFERENCES for VC10, then, no? Who is maintaining the config files for MSVC? Beman?
Regards Hartmut
--------------- Meet me at BoostCon www.boostcon.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Zachary Turner <divisortheory@gmail.com> writes:
It would be nice for them to be available in situations that arent affected by this bug. Is there a workaround that can be applied for this one case?
I could put an "if not MSVC 10" test around the boost::thread constructor. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
On Feb 18, 2010, at 3:34 AM, Anthony Williams wrote:
Zachary Turner <divisortheory@gmail.com> writes:
It would be nice for them to be available in situations that arent affected by this bug. Is there a workaround that can be applied for this one case?
I could put an "if not MSVC 10" test around the boost::thread constructor.
Perhaps a better solution would be to create a config macro HAS_MSVC_BUG_525239 and use that to control compilation of the boost::thread constructor. That way, if Microsoft fixes the bug in a service pack, the better code can be used even though it's still MSVC 10.
It would be nice for them to be available in situations that arent affected by this bug. Is there a workaround that can be applied for this one case?
I could put an "if not MSVC 10" test around the boost::thread constructor.
FWIW, it's not just the constructor. I'm getting errors all over the place in the thread library (essentially almost everywhere rvalue references are used), for instance in barrier.hpp, mutex.hpp, etc. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com
"Hartmut Kaiser" <hartmut.kaiser@gmail.com> writes:
It would be nice for them to be available in situations that arent affected by this bug. Is there a workaround that can be applied for this one case?
I could put an "if not MSVC 10" test around the boost::thread constructor.
FWIW, it's not just the constructor. I'm getting errors all over the place in the thread library (essentially almost everywhere rvalue references are used), for instance in barrier.hpp, mutex.hpp, etc.
Argh! I haven't got MSVC 10 on the machine I use for doing boost development, so I would be glad to know what the problems are. The bug I filed should only affect the boost::thread constructor, so if you change the #ifdef around that so it uses the non-rvalue-ref version for MSVC10 then that bug shouldn't bite. Anything else is new to me. Certainly, all the boost thread tests are failing on MSVC10 due to this bug. Ooh. I just found a few places where the semantics of rvalue reference binding has changed. MSVC matches the latest draft (rvalue ref doesn't bind to an lvalue), whilst g++ matches the earlier draft (rvalue ref does bind to an lvalue). Hopefully this is now fixed on trunk. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
Anthony, Sorry, but still not good: boost\thread\win32\thread_heap_alloc.hpp(97): error C2664: 'boost::detail::thread_data<F>::thread_data(F &&)' : cannot convert parameter 1 from 'void (__cdecl *)(void)' to 'void (__cdecl *&&)(void)' Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost- bounces@lists.boost.org] On Behalf Of Anthony Williams Sent: Thursday, February 18, 2010 3:55 PM To: boost@lists.boost.org Subject: Re: [boost] [thread][config] VC10RC fails compiling when using thread library (BOOST_NO_RVALUE_REFERENCES)
"Hartmut Kaiser" <hartmut.kaiser@gmail.com> writes:
It would be nice for them to be available in situations that arent affected by this bug. Is there a workaround that can be applied for this one case?
I could put an "if not MSVC 10" test around the boost::thread constructor.
FWIW, it's not just the constructor. I'm getting errors all over the place in the thread library (essentially almost everywhere rvalue references are used), for instance in barrier.hpp, mutex.hpp, etc.
Argh! I haven't got MSVC 10 on the machine I use for doing boost development, so I would be glad to know what the problems are.
The bug I filed should only affect the boost::thread constructor, so if you change the #ifdef around that so it uses the non-rvalue-ref version for MSVC10 then that bug shouldn't bite. Anything else is new to me.
Certainly, all the boost thread tests are failing on MSVC10 due to this bug.
Ooh. I just found a few places where the semantics of rvalue reference binding has changed. MSVC matches the latest draft (rvalue ref doesn't bind to an lvalue), whilst g++ matches the earlier draft (rvalue ref does bind to an lvalue). Hopefully this is now fixed on trunk.
Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Hartmut Kaiser" <hartmut.kaiser@gmail.com> writes:
Sorry, but still not good:
boost\thread\win32\thread_heap_alloc.hpp(97): error C2664: 'boost::detail::thread_data<F>::thread_data(F &&)' : cannot convert parameter 1 from 'void (__cdecl *)(void)' to 'void (__cdecl *&&)(void)'
I think that's a knock-on from the core bug. I'll try disabling the rvalue-ref thread constructor for MSVC10. If that doesn't work then rvalue refs in MSVC10 are more broken than I thought. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
On Fri, Feb 19, 2010 at 3:48 AM, Anthony Williams <anthony.ajw@gmail.com>wrote:
"Hartmut Kaiser" <hartmut.kaiser@gmail.com> writes:
Sorry, but still not good:
boost\thread\win32\thread_heap_alloc.hpp(97): error C2664: 'boost::detail::thread_data<F>::thread_data(F &&)' : cannot convert parameter 1 from 'void (__cdecl *)(void)' to 'void (__cdecl *&&)(void)'
I think that's a knock-on from the core bug. I'll try disabling the rvalue-ref thread constructor for MSVC10. If that doesn't work then rvalue refs in MSVC10 are more broken than I thought.
You can fix *all* of the original errors by applying std::move() in every case. This includes the error you reported the bug about on Microsoft Connect. I'm using 1.42, not trunk, so there may be more changes that you applied on trunk that I can't test std::move() with, but perhaps it's good practice to use std::move wherever possible anyway.
Zachary Turner <divisortheory@gmail.com> writes:
On Fri, Feb 19, 2010 at 3:48 AM, Anthony Williams <anthony.ajw@gmail.com>wrote:
"Hartmut Kaiser" <hartmut.kaiser@gmail.com> writes:
Sorry, but still not good:
boost\thread\win32\thread_heap_alloc.hpp(97): error C2664: 'boost::detail::thread_data<F>::thread_data(F &&)' : cannot convert parameter 1 from 'void (__cdecl *)(void)' to 'void (__cdecl *&&)(void)'
I think that's a knock-on from the core bug. I'll try disabling the rvalue-ref thread constructor for MSVC10. If that doesn't work then rvalue refs in MSVC10 are more broken than I thought.
You can fix *all* of the original errors by applying std::move() in every case. This includes the error you reported the bug about on Microsoft Connect.
I'm using 1.42, not trunk, so there may be more changes that you applied on trunk that I can't test std::move() with, but perhaps it's good practice to use std::move wherever possible anyway.
I'll have to install MSVC10 and boost on the same machine so I can look at this properly. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
Zachary Turner <divisortheory@gmail.com> writes:
On Fri, Feb 19, 2010 at 3:48 AM, Anthony Williams <anthony.ajw@gmail.com>wrote:
"Hartmut Kaiser" <hartmut.kaiser@gmail.com> writes:
Sorry, but still not good:
boost\thread\win32\thread_heap_alloc.hpp(97): error C2664: 'boost::detail::thread_data<F>::thread_data(F &&)' : cannot convert parameter 1 from 'void (__cdecl *)(void)' to 'void (__cdecl *&&)(void)'
I think that's a knock-on from the core bug. I'll try disabling the rvalue-ref thread constructor for MSVC10. If that doesn't work then rvalue refs in MSVC10 are more broken than I thought.
You can fix *all* of the original errors by applying std::move() in every case. This includes the error you reported the bug about on Microsoft Connect.
That's not entirely true. If you apply std::move (or equivalently static_cast<T&&>, as I have now done on trunk) then the primary bug still hits you if you try and pass the a plain function as the thread function. I've fixed this on trunk by masking the rvalue-reference thread constructor for MSVC10. I think the thread lib is now in much better shape for MSVC10. There were a few failures when I ran the tests, which I'll tend to later, but most passed. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
Anthony Williams <anthony.ajw <at> gmail.com> writes:
I think that's a knock-on from the core bug. I'll try disabling the rvalue-ref thread constructor for MSVC10. If that doesn't work then rvalue refs in MSVC10 are more broken than I thought.
f.y.i, The thread regression tests are now pretty much all failing on VC10RC with syntax errors in thread/detail/thread.hpp. e.g. http://tinyurl.com/yaw8x2w
On Feb 18, 2010, at 3:34 AM, Anthony Williams wrote:
Zachary Turner <divisortheory@gmail.com> writes:
It would be nice for them to be available in situations that arent affected by this bug. Is there a workaround that can be applied for this one case?
I could put an "if not MSVC 10" test around the boost::thread constructor.
Perhaps a better solution would be to create a config macro HAS_MSVC_BUG_525239 and use that to control compilation of the boost::thread constructor. That way, if Microsoft fixes the bug in a service pack, the better code can be used even though it's still MSVC 10.
Hi all, I have problems including <boost/asio.hpp> in a .h source file on Solaris 10 x86, boost version 1_42. g++ complains as follows: In file included from /usr/include/sys/socket.h:38, from /usr/local/include/boost/asio/detail/socket_types.hpp:104, from /usr/local/include/boost/asio/detail/win_iocp_io_service_fwd.hpp:24, from /usr/local/include/boost/asio/io_service.hpp:37, from /usr/local/include/boost/asio/basic_io_object.hpp:20, from /usr/local/include/boost/asio/basic_socket.hpp:24, from /usr/local/include/boost/asio/basic_datagram_socket.hpp:25, from /usr/local/include/boost/asio.hpp:20, from POSIX_CommConnection.h:7, from Connector.cpp:2: /usr/include/sys/uio.h:72: error: `uint16_t' does not name a type $ uname -a SunOS unknown0019994802a5 5.10 Generic_141445-09 i86pc i386 i86pc Has someone managed to include boost::asio? Best regards, Ricard de Benito Panillo
AMDG Ricard de Benito Panillo wrote:
I have problems including <boost/asio.hpp> in a .h source file on Solaris 10 x86, boost version 1_42. g++ complains as follows:
In file included from /usr/include/sys/socket.h:38, from /usr/local/include/boost/asio/detail/socket_types.hpp:104, from /usr/local/include/boost/asio/detail/win_iocp_io_service_fwd.hpp:24, from /usr/local/include/boost/asio/io_service.hpp:37, from /usr/local/include/boost/asio/basic_io_object.hpp:20, from /usr/local/include/boost/asio/basic_socket.hpp:24, from /usr/local/include/boost/asio/basic_datagram_socket.hpp:25, from /usr/local/include/boost/asio.hpp:20, from POSIX_CommConnection.h:7, from Connector.cpp:2: /usr/include/sys/uio.h:72: error: `uint16_t' does not name a type
$ uname -a SunOS unknown0019994802a5 5.10 Generic_141445-09 i86pc i386 i86pc
Has someone managed to include boost::asio?
What happens if you just #include <sys/socket.h> In Christ, Steven Watanabe P.S. Please don't reply to an existing thread with a new subject.
participants (7)
-
Anthony Williams -
Hartmut Kaiser -
Ian Emmons -
Ricard de Benito Panillo -
Richard Webb -
Steven Watanabe -
Zachary Turner