"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