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

On Wed, Jun 27, 2012 at 7:46 AM, Brian Wood <woodbrian77@gmail.com> wrote:
Emil Dotchevski:
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
Emil Dotchevski: 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.
I'm not asking for this to be the default even for single threaded programs. I'd like it to be something that a user could opt out of if they want to. (This is all based on the possibilty that Boost Exception could become required. If that doesn't happen, this request wouldn't be very pressing from my perspective.) I haven't found much on use cases in single threaded programs. Do you have any links? I did find the following comment in some code that uses exception_ptr. "The reason here is that construction/destruction of an exception_ptr are not "cheap"" Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

On Thu, Jun 28, 2012 at 10:42 AM, Brian Wood <woodbrian77@gmail.com> wrote:
I haven't found much on use cases in single threaded programs. Do you have any links? I did find the following comment in some code that uses exception_ptr.
Any time when a failure can't be handled at the time it is reported, which usually involves asynchronous operations, which usually involves multiple threads.
"The reason here is that construction/destruction of an exception_ptr are not "cheap""
Calling boost::throw_exception doesn't construct or destruct exception_ptr objects. Any use of boost::exception_ptr requires #including <boost/exception_ptr.hpp>. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

Le 28/06/12 22:16, Emil Dotchevski a écrit :
On Thu, Jun 28, 2012 at 10:42 AM, Brian Wood<woodbrian77@gmail.com> wrote:
I haven't found much on use cases in single threaded programs. Do you have any links? I did find the following comment in some code that uses exception_ptr.
Any time when a failure can't be handled at the time it is reported, which usually involves asynchronous operations, which usually involves multiple threads.
"The reason here is that construction/destruction of an exception_ptr are not "cheap""
Calling boost::throw_exception doesn't construct or destruct exception_ptr objects. Any use of boost::exception_ptr requires #including <boost/exception_ptr.hpp>.
Does the use of BOOST_THROW_EXCEPTION implies the use of exception_ptr? Best, Vicente

On Thu, Jun 28, 2012 at 11:53 PM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:
Does the use of BOOST_THROW_EXCEPTION implies the use of exception_ptr?
BOOST_THROW_EXCEPTION simply captures information about the throw location, then calls boost::throw_exception. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

Le 29/06/12 09:17, Emil Dotchevski a écrit :
On Thu, Jun 28, 2012 at 11:53 PM, Vicente J. Botet Escriba< vicente.botet@wanadoo.fr> wrote:
Does the use of BOOST_THROW_EXCEPTION implies the use of exception_ptr?
BOOST_THROW_EXCEPTION simply captures information about the throw location, then calls boost::throw_exception.
I see that template<class E> BOOST_ATTRIBUTE_NORETURN inline void throw_exception( E const & e ) { //All boost exceptions are required to derive from std::exception, //to ensure compatibility with BOOST_NO_EXCEPTIONS. throw_exception_assert_compatibility(e); #ifndef BOOST_EXCEPTION_DISABLE throw enable_current_exception(enable_error_info(e)); #else throw e; #endif } From the documentation, enable_current_exception let me think that we not only BOOST_THROW_EXCEPTION but boost::throw_exception immplies the use of exception_ptr, isn't it? Am I missing something evident? Best, Vicente enable_current_exception #include <boost/exception/enable_current_exception.hpp> namespace boost { template<class T> ---unspecified---enable_current_exception( T const& e ); } Requirements: * T must be a class with an accessible no-throw copy constructor. * If T has any virtual base types, those types must have an accessible default constructor. Returns: An object of /unspecified/ type which derives publicly from T. That is, the returned object can be intercepted by a catch(T &). Description: This function is designed to be used directly in a throw-expression to enable the exception_ptr support in Boost Exception. For example: class my_exception: public std::exception { }; .... throw boost::enable_current_exception(my_exception()); Unless enable_current_exception is called at the time an exception object is used in a throw-expression, an attempt to copy it using current_exception may return an exception_ptr which refers to an instance of unknown_exception. See current_exception for details. Note: Instead of using the throw keyword directly, it is preferable to call boost::throw_exception. This is guaranteed to throw an exception that derives from boost::exception and supports the exception_ptr functionality.

on Thu Jun 28 2012, Brian Wood <woodbrian77-AT-gmail.com> wrote:
Emil Dotchevski:
On Wed, Jun 27, 2012 at 7:46 AM, Brian Wood <woodbrian77@gmail.com> wrote:
There are exception_ptr use cases for single threaded programs.
I'm not asking for this to be the default even for single threaded programs. I'd like it to be something that a user could opt out of if they want to.
I believe what you're asking for is a micro-optimization that would never show up as significant in any real program. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (4)
-
Brian Wood
-
Dave Abrahams
-
Emil Dotchevski
-
Vicente J. Botet Escriba