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

Pete Bartlett: < snip >
Cons for 1) and 2): - Always paying for the cost of #including <boost/throw_exception.hpp> - All libraries are dependent on - and therefore become vulnerable to any future breakages (if any) in - Boost.Exception.
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? Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

On Tue, Jun 26, 2012 at 10:24 AM, Brian Wood <woodbrian77@gmail.com> wrote:
Pete Bartlett:
< snip >
Cons for 1) and 2): - Always paying for the cost of #including <boost/throw_exception.hpp> - All libraries are dependent on - and therefore become vulnerable to any future breakages (if any) in - Boost.Exception.
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. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
participants (2)
-
Brian Wood
-
Emil Dotchevski