Bugzilla from anthony.ajw@gmail.com wrote:
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?
Hi, the use of boost::throw_exception is welcome but more for the ability this function provides to store a pointer to an exception than the ability to disable exception. If in addition you use some ifdefs to mask features that are not easy to provide without exceptions the reporter of the ticket could use Boost.Thread on an environment that has or requires no exceptions. I don't understand however how an application can work without taking care of errors. Just my point of view. Thanks, Vicente -- View this message in context: http://old.nabble.com/-thread--Bug-sprint%3A--2100-thread-fails-to-compile-w... Sent from the Boost - Dev mailing list archive at Nabble.com.