[boost] Has someone any plans to submit a exception_ptr library to Boost? (was Review Request: future library (Gaskill version))

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-04-14 04:50:44

From: "Peter Dimov" <pdimov_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, April 13, 2008 11:54 PM
Subject: Re: [boost] Review Request: future library (Gaskill version)

> vicente.botet:
>> Hello Peter,
>>
>> this future library use your exception_ptr (providing a partial emulation 
>> of
>> N2179) and as I supose should be the case of any future implementation.
>>
>> Do you plan to submit your implementation to Boost?
> 
> My implementation is merely a proof of concept. I know Anthony Williams has 
> one (specific to MSVC) that is much more impressive (although I don't see it 
> in the SVN). I see that Emil Dotchevski also has something along these lines 
> in boost/exception/cloning.hpp. The future library also seems to contain an 
> enhanced implementation. 
 
Peter, thanks for the references. libpoet has also another one based on yours.

With the yours this give us 5 exception_ptr implementations, and I suppose that there are others in the field.

Kowalke Oliver has just port a proposal to manage with user exceptions on the context of the future library, passing a mpl::vector of user exceptions to the point which could throw the exception. 
I need to think a little bit to see if this could be adapted to the exception_ptr library.

Anthony, can I take a look to your implementation? 

I have make a comparaison between the 4 implementations.  

0.a  copy_exception/clone_exception : EXCEPTION use clone and works well for exceptions inheriting either from boost::clone_base either from boost::exception. For the other store a unknown_exception
0.b current_exception not provided by EXCEPTION 
1.a  _exp_throwable has virtual destructor: FUTURE & POET
1.b  template< class E > class _exp_throwable_impl  has virtual destructor: FUTURE
2  exception_ptr _exp_current_exception
    a  _CATCH_AND_RETURN/_CATCH_AND_RETURN_WHAT: POET return the result of what() of the exceptions instead of the exception iteself for standard exceptions.
    b  catch and return exceptions: each implementation use a limited set of exceptions, the standard ones, the boost ones for FUTURE & POET,and the specific exception of each library FUTURE & POET
    c  catch and return for std::exception: PETER & FUTURE store std::run_time (with the std::exception::what() result),POET stores boost::unknown_exception

    d catch and return for bad_alloc: FUTURE as  a header_only library has an static initialization of s_bad_alloc (Why POET don't have it)
3  header_only: FUTURE & POET

1.a 1.b This seams not necessary, shared pointer calls to the correct destructor given on the construtor not the ~T, as Peter as already explained in other posts.

2.a the catch and return needs to preserv the exception as much as possible, so _CATCH_AND_RETURN should be used instead of _CATCH_AND_RETURN_WHAT
_CATCH_AND_RETURN should be boostyfied BOOST_EXCEPTION_PRT_CATCH_AND_RETURN and should be undefined at the end of the file. This should be evident for most of the boosters, but why we need this tranformation?

2.b This is the most conflictual point. It is clear that _exp_current_exception will have always a limited set of exceptions. So why not let its definition to the user, providing some mechanisms facilitating the user task. 

2.c, 2.b Peter could you explain why we need to transform std::exception and std::bad_alloc onto other exception

2.d The current_exception definition must be in a single compilation unit, and so it can be in the if the point 2.b _exp_current_exception definition is let to the user there is no static initialization problem because the variable is defined in one single compilation unit.

3 As the class is not a template a binary library is possible. If _exp_current_exception is defined by the library this has the liability that the _exp_current_exception will take in account a limited number of exceptions.
By the size of the library, a header only library seams also a good choice if the point 2.b _exp_current_exception definition is let to the user. The user can define this in a separated compilation unit.

I have attached a exception_ptr.cpp file which must be compiled separately by the user. The user can define BOOST_EXCEPTION_PTR_CATCH_AND_RETURN_USER_EXCEPTIONS__HPP with the file including the user catch and return specifics.

I know that this is not very elegant, but considering that this is only an emulatuion ...

Anthony, can your implementation improve this issues? 

Has someone any plans to submit a exception_ptr library to Boost?

Best regards

_____________________
Vicente Juan Botet Escriba