Re: [boost] Policy proposal: All user-visible exceptions should be thrown through BOOST_THROW_EXCEPTION

Emil Dotchevski:
On Tue, Jun 26, 2012 at 10:24 AM, Brian Wood <woodbrian77@gmail.com> wrote:
Is there a penalty for single threaded applications here? There's been discussion of the support for transferring exceptions between threads; are there aspects of that support that are unneeded in a single threaded context?
There are 3 aspects of boost::throw_exception:
1) it enables libraries to support BOOST_NO_EXCEPTIONS configurations, 2) it enables boost::error_info, and 3) it enables boost::exception_ptr.
1) and 2) have nothing to do with threads; 3) implements std::exception_ptr, which mostly benefits multi-thread programs (until compilers catch up with std::exception_ptr support.)
The cost imposed by libraries that use boost::throw_exception to programs that don't use boost::exception_ptr or boost::error_info is that sizeof() the exception object grows a little.
I'd appreciate a way at compile time to let Boost Exception know I'm using it in a single threaded application and it wouldn't add stuff to the exception object that isn't needed. Also MSDN says, "Most applications do not have to transport exceptions between threads." Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

On Wed, Jun 27, 2012 at 7:46 AM, Brian Wood <woodbrian77@gmail.com> wrote:
Emil Dotchevski:
On Tue, Jun 26, 2012 at 10:24 AM, Brian Wood <woodbrian77@gmail.com> wrote:
Is there a penalty for single threaded applications here? There's been discussion of the support for transferring exceptions between threads; are there aspects of that support that are unneeded in a single threaded context?
There are 3 aspects of boost::throw_exception:
1) it enables libraries to support BOOST_NO_EXCEPTIONS configurations, 2) it enables boost::error_info, and 3) it enables boost::exception_ptr.
1) and 2) have nothing to do with threads; 3) implements std::exception_ptr, which mostly benefits multi-thread programs (until compilers catch up with std::exception_ptr support.)
The cost imposed by libraries that use boost::throw_exception to programs that don't use boost::exception_ptr or boost::error_info is that sizeof() the exception object grows a little.
I'd appreciate a way at compile time to let Boost Exception know I'm using it in a single threaded application and it wouldn't add stuff to the exception object that isn't needed. Also MSDN says, "Most applications do not have to transport exceptions between threads."
There are exception_ptr use cases for single threaded programs. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

There are exception_ptr use cases for single threaded programs.
As an example, I've written an ASIO-based application that makes use of callbacks where one of the arguments is an exception_ptr. If the exception_ptr is not null then it contains the exception that occurred during the requested operation. It can run with a single thread and the exception transporting would still be useful. Before I used exception transporting I was passing a status indicator which was not nearly as nice. -- Brant
participants (3)
-
Brant Knudson
-
Brian Wood
-
Emil Dotchevski