Vicente Botet Escriba <vicente.botet@wanadoo.fr> writes:
Ticket description: "The thread component fails to compile with GCC when -fno-exceptions is specified. The attached patch allows the libraries / tests shipped with boost 1.35.0 to compile. There didn't seem to be a better option to make g++ happy than to just #ifndef out the catch(...) block, as it would otherwise complain about the throw in the block." from https://svn.boost.org/trac/boost/ticket/2100
Hi, I think that Boost.Thread has not been designed to work without exception. What would be the behavior of the application if we remove just any throw statement? In order to achieve the reporter goal, we should need to add functions returning a return code. IMO this is out of the scope currently. Thus I propose to close the ticket.
I've committed a change to trunk that uses boost::throw_exception in most cases. The only cases I haven't touched are where thread_interrupted is thrown at a cancellation point. As you say, Boost.Thread has not been designed to work without exceptions. In most cases this is not a problem, but interruption relies on exceptions to work properly. I'm therefore inclined to think that interruption should not be available with exceptions disabled, in which case this code can be masked with a #ifdef What do you think? 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