Has someone any plans to submit a exception_ptr library to Boost? (was Review Request: future library (Gaskill version))
From: "Peter Dimov" <pdimov@pdimov.com> To: <boost@lists.boost.org> 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
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
Anthony, can I take a look to your implementation?
Sure. I've attached it here. It uses direct access to the MSVC exception mechanism to clone ANY exception for later rethrow. It works for MSVC 7.1 and MSVC 8.0. I've not tried it with any other version. It will NOT work with any other compiler (though it might be adapted to do so).
Has someone any plans to submit a exception_ptr library to Boost?
I posted this to the boost list earlier, in the hope that it could be incorporated into boost.exception. I would be VERY happy for it to be part of boost. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
I'm sorry - the exception_ptr_impl.hpp needs a modification (case where no user defined types are passed). Now it's corrected. Oliver /*************************************************************************** * Copyright (C) 2008 by Oliver Kowalke * * kowalke@drslx002 * * * * This program is free software; you can redistribute it and/or modify * * it under the terms of the GNU General Public License as published by * * the Free Software Foundation; either version 2 of the License, or * * (at your option) any later version. * * * * This program is distributed in the hope that it will be useful, * * but WITHOUT ANY WARRANTY; without even the implied warranty of * * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * * GNU General Public License for more details. * * * * You should have received a copy of the GNU General Public License * * along with this program; if not, write to the * * Free Software Foundation, Inc., * * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. * ***************************************************************************/ #ifdef HAVE_CONFIG_H #include <config.h> #endif #include <iostream> #include <cstdlib> #include <stdexcept> #include <boost/bind.hpp> #include <boost/mpl/vector.hpp> #include <boost/thread.hpp> #include <future.hpp> struct X { std::string msg; X( std::string const& msg_) : msg( msg_) {} }; int add( int a, int b) { throw X("X error"); return a + b; } void execute( boost::function< void() > fn) { fn(); } int main( int argc, char *argv[]) { try { boost::promise< int > p; boost::future_wrapper< int, boost::mpl::vector< X > > wrapper( // boost::future_wrapper< int > wrapper( boost::bind( add, 11, 13), p); boost::future< int > f( p); boost::thread t( boost::bind( & execute, wrapper) ); std::cout << "add = " << f.get() << std::endl; return EXIT_SUCCESS; } catch ( X const& x) { std::cerr << x.msg << std::endl; } catch ( std::exception const& e) { std::cerr << e.what() << std::endl; } catch ( ... ) { std::cerr << "unhandled exception" << std::endl; } return EXIT_FAILURE; }
Thank you very much Olivier, I start to really appreciate your solution even if the interface of the current_exception and copy_exception functions change. The main question of the mail has not yet a response. Olivier? _____________________ Vicente Juan Botet Escriba ----- Original Message ----- From: "Kowalke Oliver (QD IT PA AS)" <Oliver.Kowalke@qimonda.com> To: <boost@lists.boost.org> Sent: Monday, April 14, 2008 2:53 PM Subject: Re: [boost] Has someone any plans to submit a exception_ptrlibrary to Boost? I'm sorry - the exception_ptr_impl.hpp needs a modification (case where no user defined types are passed). Now it's corrected. Oliver /*************************************************************************** * Copyright (C) 2008 by Oliver Kowalke * * kowalke@drslx002 * * * * This program is free software; you can redistribute it and/or modify * * it under the terms of the GNU General Public License as published by * * the Free Software Foundation; either version 2 of the License, or * * (at your option) any later version. * * * * This program is distributed in the hope that it will be useful, * * but WITHOUT ANY WARRANTY; without even the implied warranty of * * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * * GNU General Public License for more details. * * * * You should have received a copy of the GNU General Public License * * along with this program; if not, write to the * * Free Software Foundation, Inc., * * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. * ***************************************************************************/#ifdef HAVE_CONFIG_H#include <config.h>#endif#include <iostream>#include <cstdlib>#include <stdexcept>#include <boost/bind.hpp>#include <boost/mpl/vector.hpp>#include <boost/thread.hpp>#include <future.hpp>struct X{ std::string msg; X( std::string const& msg_) : msg( msg_) {}};int add( int a, int b){ throw X("X error"); return a + b; }void execute( boost::function< void() > fn){ fn(); }int main( int argc, char *argv[]){ try { boost::promise< int > p; boost::future_wrapper< int, boost::mpl::vector< X > >wrapper( // boost::future_wrapper< int > wrapper( boost::bind( add, 11, 13), p); boost::future< int > f( p); boost::thread t( bo ost::bind( & execute, wrapper) ); std::cout << "add = " << f.get() << std::endl; return EXIT_SUCCESS; } catch ( X const& x) { std::cerr << x.msg << std::endl; } catch ( std::exception const& e) { std::cerr << e.what() << std::endl; } catch ( ... ) { std::cerr << "unhandled exception" << std::endl; } return EXIT_FAILURE;}--------------------------------------------------------------------------------> _______________________________________________> Unsubscribe & other changes:http://lists.boost.org/mailman/listinfo.cgi/boost
Anthony Williams wrote:
"vicente.botet" <vicente.botet@wanadoo.fr> writes:
Anthony, can I take a look to your implementation?
Sure. I've attached it here. It uses direct access to the MSVC exception mechanism to clone ANY exception for later rethrow. It works for MSVC 7.1 and MSVC 8.0. I've not tried it with any other version. It will NOT work with any other compiler (though it might be adapted to do so).
Very impressive (and very ugly, but messing with compiler internals is like that). I looked into GCC's language support library, but it seems that GCC doesn't store the copy constructor of the thrown object anywhere - neither in the exception header, nor in the type info. This is very unfortunate, since it means that a similar implementation is not possible for GCC. Sebastian Redl
Sebastian Redl:
I looked into GCC's language support library, but it seems that GCC doesn't store the copy constructor of the thrown object anywhere - neither in the exception header, nor in the type info. This is very unfortunate, since it means that a similar implementation is not possible for GCC.
Note that N2179 doesn't require a copy to be made. If GCC allocates the exception objects on a heap - I have some recollections that it was doing that but I may be wrong - it might still be possible to implement current_exception to return a pointer to the active exception object... if there's a way to insert a reference count somewhere inside.
Peter Dimov wrote:
Note that N2179 doesn't require a copy to be made. If GCC allocates the exception objects on a heap - I have some recollections that it was doing that but I may be wrong No, you're right. It goes through malloc() first, but should that fail, it has a small separate "emergency" area. - it might still be possible to implement current_exception to return a pointer to the active exception object... if there's a way to insert a reference count somewhere inside.
That's a good idea. There *is* a reference count in there. I think I can do something with that. Sebastian
Peter Dimov wrote:
Note that N2179 doesn't require a copy to be made. If GCC allocates the exception objects on a heap - I have some recollections that it was doing that but I may be wrong - it might still be possible to implement current_exception to return a pointer to the active exception object... if there's a way to insert a reference count somewhere inside.
I took a larger stab at this, but I'm pretty much stumped right now. I can't abuse the reference count in __cxa_exception, because if I do, the handled exception stack won't be properly cleaned up. I can use current_exception() to get the currently handled exception. However, calling it again will yield a null pointer. That's because I can't abuse handlerCount properly. The exception_ptr works so far that it lets the exception escape the catch. I can use rethrow_exception() to rethrow the exception. However, when I catch it again, it won't escape the catch. I.e. ------------- class foo {}; int main() { exception_ptr p; try { throw foo(); } catch(foo &) { p = current_exception(); // Every subsequent current_exception() == 0 } try { rethrow_exception(p); } catch(foo &) { } // Exception is destroyed here! // p dangles here! } -------------- And that's a simple scenario ... Sebastian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 15 April 2008 13:19 pm, Sebastian Redl wrote:
Peter Dimov wrote:
Note that N2179 doesn't require a copy to be made. If GCC allocates the exception objects on a heap - I have some recollections that it was doing that but I may be wrong - it might still be possible to implement current_exception to return a pointer to the active exception object... if there's a way to insert a reference count somewhere inside.
I took a larger stab at this, but I'm pretty much stumped right now. I can't abuse the reference count in __cxa_exception, because if I do, the handled exception stack won't be properly cleaned up.
I've never worked with compiler-internal kinds of things, but here's my attempt at a helpful suggestion. Instead of modifying the reference count, is it possible to do anything with the __cxa_exception::unwindHeader.exception_cleanup function pointer? Maybe you could replace it with something that doesn't actually destroy the exception object, and then have the exception_ptr take ownership. You also have access to the exception's destructor with the __cxa_exception::exceptionDestructor function pointer, although I think even if you replaced this with a null destructor, it would still free the memory for the exception object. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIBPLC5vihyNWuA4URAsrMAJ99mt85DsrRedUc/Bqr19CZsLaN6ACdFk6a vojRZ2JNmY+cm+dMwsNCT9c= =6g1K -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 15 April 2008 13:19, Sebastian Redl wrote:
I can use current_exception() to get the currently handled exception. However, calling it again will yield a null pointer. That's because I can't abuse handlerCount properly.
The exception_ptr works so far that it lets the exception escape the catch.
I can use rethrow_exception() to rethrow the exception. However, when I catch it again, it won't escape the catch. I.e.
Here's a partial proof-of-concept implementation of exception_ptr for Linux, tested on gcc 4.1.2. The unwind-cxx.h file is just a copy from the gcc source: gcc-4.1.1/libstdc++-v3/libsupc++/unwind-cxx.h. The test program demonstrates that you can rethrow more than once. There is no implementation for copy_exception() yet. If you call current_exception multiple times for one exception, it will probably crash. That should be fixable by adding a global/singleton map which would let you find if another exception_ptr already owns a particular exception object. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIC05l5vihyNWuA4URAqg+AJ98TobpjS4c/FTeHe5A99s9ypqa8ACgsUL0 DKE8VEMc+KbX7z3J6lxj50Q= =hZv9 -----END PGP SIGNATURE-----
Frank Mori Hess wrote:
Here's a partial proof-of-concept implementation of exception_ptr for Linux, tested on gcc 4.1.2. Have you tested this case:
void fn() { exception_ptr p; try { throw runtime_error("hello, world"); } catch(...) { p = current_exception(); } rethrow_exception(p); } int main() { try { fn(); } catch(runtime_error &e) { std::cerr << e.what() << '\n'; } } I believe your scheme will delete the exception object when p goes out of scope, so either the exception mechanism itself will crash, or e will be dangling. Testing this out proves it. If I add some output statements, I get: Rethrowing. virtual test_exception::~test_exception() Caught in main. Even though it happens not to crash my simple scenario, it shows clearly that the exception is destructed before it is caught in main. This is still too simple, unfortunately. Replacing the cleanup function is a good idea, but it's not enough to get around the limitations of this method. I played around with it all day today. I'm currently trying my next play: I need more data reachable from the exception object, so I'm going to make it reachable. My plan is to let the cleanup function pointer point to a structure whose first bytes contain the code of a function that simply returns. In other words, I hide more data behind the cleanup function. Wish me luck. :-) Sebastian
On Sunday 20 April 2008 15:07, Sebastian Redl wrote:
This is still too simple, unfortunately. Replacing the cleanup function is a good idea, but it's not enough to get around the limitations of this method. I played around with it all day today.
Yes, it needs to do something like create another copy of the exception_ptr which is deleted by the exception_cleanup function.
I'm currently trying my next play: I need more data reachable from the exception object, so I'm going to make it reachable. My plan is to let the cleanup function pointer point to a structure whose first bytes contain the code of a function that simply returns. In other words, I hide more data behind the cleanup function. Wish me luck. :-)
Another thing that's occurred to me is, are there license issues with boost-licensed code using internal interfaces in libsupc++? Maybe the best route is to just send a patch to the gcc people that implements exception_ptr as a gnu extension? That would also give you more freedom in your implementation choices. -- Frank
Another thing that's occurred to me is, are there license issues with boost-licensed code using internal interfaces in libsupc++? Possibly. I'm not sure if the linking exception that applies to all of GCC's libraries includes explicit naming of internal interfaces. (GCC generates code that links against those things, so obviously the mere existence of the links in object code is no problem.) I don't think it's a problem, but IANAL. What's IMO a greater problem is
Frank Mori Hess wrote: the partial duplicate of GPL-licensed code. In my code, I've written the structs myself, and they consist mostly of dummy entries, but it's still basically a copy.
Maybe the best route is to just send a patch to the gcc people that implements exception_ptr as a gnu extension? That would also give you more freedom in your implementation choices.
I've considered it. But 1) First I need to get it to work - as you say, I've got more choices with a change to libsupc++, but at a big cost. 2) Changing the current thing would break the C++ ABI! This is a huge thing to consider. 3) Effectively, I'd have to compile my own GCC, and make it use my own libsupc++. This is far from trivial. We'll see. First I get it to work, then I'll consider what to do with the code. Sebastian
Sebastian Redl:
Maybe the best route is to just send a patch to the gcc people that implements exception_ptr as a gnu extension? That would also give you more freedom in your implementation choices.
I've considered it. But 1) First I need to get it to work - as you say, I've got more choices with a change to libsupc++, but at a big cost. 2) Changing the current thing would break the C++ ABI! This is a huge thing to consider. 3) Effectively, I'd have to compile my own GCC, and make it use my own libsupc++. This is far from trivial.
We'll see. First I get it to work, then I'll consider what to do with the code.
Maybe you should ask on the libstdc++ list if there's interest?
On Sunday 20 April 2008 16:01, Sebastian Redl wrote:
Frank Mori Hess wrote:
Maybe the best route is to just send a patch to the gcc people that implements exception_ptr as a gnu extension? That would also give you more freedom in your implementation choices.
I've considered it. But 1) First I need to get it to work - as you say, I've got more choices with a change to libsupc++, but at a big cost. 2) Changing the current thing would break the C++ ABI! This is a huge thing to consider.
It seems inevitable that the C++ ABI at least be extended if exception_ptr is to ever be standardized. Clearly, the existing ABI is insufficient to implement exception_ptr. -- Frank
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 20 April 2008 15:07 pm, Sebastian Redl wrote:
This is still too simple, unfortunately. Replacing the cleanup function is a good idea, but it's not enough to get around the limitations of this method. I played around with it all day today.
I'm currently trying my next play: I need more data reachable from the exception object, so I'm going to make it reachable. My plan is to let the cleanup function pointer point to a structure whose first bytes contain the code of a function that simply returns. In other words, I hide more data behind the cleanup function. Wish me luck. :-)
I've worked a little more on my version, I think it's fully functional now. It's not particularly efficient, but it seems to work. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIDOAD5vihyNWuA4URAhirAKDpJXOBVbvrez1ggDJ/aL0zMOA69wCg5K94 QLSdLPbfUMx53bfPEjo30V4= =xh9o -----END PGP SIGNATURE-----
On 4/14/08, Anthony Williams <anthony_w.geo@yahoo.com> wrote:
I posted this to the boost list earlier, in the hope that it could be incorporated into boost.exception. I would be VERY happy for it to be part of boost.
I've just committed changes to the Boost Exception cloning support to make it N2179-complient. The implementation of current_exception() is similar to http://www.pdimov.com/cpp/N2179/exception_ptr.cpp. I will update the Boost Exception documentation soon. Antony, I would also like to incorporate your MSVC-specific support into Boost Exception. Without such compiler-specific support, for current_exception() to fully work, the user must call enable_current_exception() (which is part of Boost Exception) at the time of the throw. The plan is to make this call automatic directly in boost::throw_exception() (I will commit that change to boost/throw_exception.hpp as soon as I see the relevant Boost Exception tests pass on all supported platforms.) -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
"Emil Dotchevski" <emil@revergestudios.com> writes:
On 4/14/08, Anthony Williams <anthony_w.geo@yahoo.com> wrote:
I posted this to the boost list earlier, in the hope that it could be incorporated into boost.exception. I would be VERY happy for it to be part of boost.
I've just committed changes to the Boost Exception cloning support to make it N2179-complient. The implementation of current_exception() is similar to http://www.pdimov.com/cpp/N2179/exception_ptr.cpp.
I will update the Boost Exception documentation soon.
Antony, I would also like to incorporate your MSVC-specific support into Boost Exception. Without such compiler-specific support, for current_exception() to fully work, the user must call enable_current_exception() (which is part of Boost Exception) at the time of the throw. The plan is to make this call automatic directly in boost::throw_exception() (I will commit that change to boost/throw_exception.hpp as soon as I see the relevant Boost Exception tests pass on all supported platforms.)
That's excellent news. Thanks, Emil. Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
--------------------------- Vicente Juan Botet Escriba ----- Original Message ----- From: "Anthony Williams" <anthony_w.geo@yahoo.com> To: <boost@lists.boost.org> Sent: Tuesday, April 15, 2008 9:18 PM Subject: Re: [boost] Has someone any plans to submit a exception_ptr libraryto Boost?
"Emil Dotchevski" <emil@revergestudios.com> writes:
On 4/14/08, Anthony Williams <anthony_w.geo@yahoo.com> wrote:
I posted this to the boost list earlier, in the hope that it could be incorporated into boost.exception. I would be VERY happy for it to be part of boost.
I've just committed changes to the Boost Exception cloning support to make it N2179-complient. The implementation of current_exception() is similar to http://www.pdimov.com/cpp/N2179/exception_ptr.cpp.
I will update the Boost Exception documentation soon.
Antony, I would also like to incorporate your MSVC-specific support into Boost Exception. Without such compiler-specific support, for current_exception() to fully work, the user must call enable_current_exception() (which is part of Boost Exception) at the time of the throw. The plan is to make this call automatic directly in boost::throw_exception() (I will commit that change to boost/throw_exception.hpp as soon as I see the relevant Boost Exception tests pass on all supported platforms.)
That's excellent news. Thanks, Emil.
I'm really happy that you Emil, the author of the Exception library takes this responsability. BTW, I have updated the boost/exception directory and I'm unable to find current_exception, neither rethrow_exception. I supose that there has been a issue with the SVN repository. The clonning.hpp is not anymore there. enable_current_exception.hpp enable_error_info.hpp error_info.hpp exception.hpp info.hpp info_tuple.hpp to_string.hpp to_string_stub.hpp Have I missed something? Best regards
Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Sorry, I see the exception_ptr.hpp file is directly on the boost directory. _____________________ Vicente Juan Botet Escriba ----- Original Message ----- From: "vicente.botet" <vicente.botet@wanadoo.fr> To: <boost@lists.boost.org> Sent: Tuesday, April 15, 2008 9:59 PM Subject: Re: [boost] Has someone any plans to submit a exception_ptrlibraryto Boost?
----- Original Message ----- From: "Anthony Williams" <anthony_w.geo@yahoo.com> To: <boost@lists.boost.org> Sent: Tuesday, April 15, 2008 9:18 PM Subject: Re: [boost] Has someone any plans to submit a exception_ptr libraryto Boost?
"Emil Dotchevski" <emil@revergestudios.com> writes:
On 4/14/08, Anthony Williams <anthony_w.geo@yahoo.com> wrote:
I posted this to the boost list earlier, in the hope that it could be incorporated into boost.exception. I would be VERY happy for it to be part of boost.
I've just committed changes to the Boost Exception cloning support to make it N2179-complient. The implementation of current_exception() is similar to http://www.pdimov.com/cpp/N2179/exception_ptr.cpp.
I will update the Boost Exception documentation soon.
Antony, I would also like to incorporate your MSVC-specific support into Boost Exception. Without such compiler-specific support, for current_exception() to fully work, the user must call enable_current_exception() (which is part of Boost Exception) at the time of the throw. The plan is to make this call automatic directly in boost::throw_exception() (I will commit that change to boost/throw_exception.hpp as soon as I see the relevant Boost Exception tests pass on all supported platforms.)
That's excellent news. Thanks, Emil.
I'm really happy that you Emil, the author of the Exception library takes this responsability.
BTW, I have updated the boost/exception directory and I'm unable to find current_exception, neither rethrow_exception.
I supose that there has been a issue with the SVN repository. The clonning.hpp is not anymore there.
enable_current_exception.hpp enable_error_info.hpp error_info.hpp exception.hpp info.hpp info_tuple.hpp to_string.hpp to_string_stub.hpp
Have I missed something?
Best regards
Anthony -- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 4/15/08, vicente.botet <vicente.botet@wanadoo.fr> wrote:
Sorry, I see the exception_ptr.hpp file is directly on the boost directory.
I apologize for not saying where it was. :) I have just updated the Boost Exception documentation in SVN as well. Copy of the documentation is available online at http://www.revergestudios.com/boost-exception/boost-exception.html. Feedback is much appreciated. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 14 April 2008 04:50 am, vicente.botet wrote:
1.a _exp_throwable has virtual destructor: FUTURE & POET 1.b template< class E > class _exp_throwable_impl has virtual destructor: FUTURE
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
Ah, thanks for noticing that problem in libpoet. I think it's fixed now, using a template static trick: http://www.comedi.org/cgi-bin/viewvc.cgi/libpoet/poet/exception_ptr.cpp?r1=1.6&r2=1.7 Something like that may be helpful in Braddock's lib, since his comments indicate concern about the allocation probably failing.
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.
It may be worthwhile nontheless, since it quiets the "virtual functions without virtual destructor" warning from gcc. That could save you bogus bug reports and maybe even a FAQ entry. Since the class already has a virtual function, making the destructor virtual doesn't add any per-object overhead, right? - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIA4Tf5vihyNWuA4URAiTNAKCkz05zmqZjaH7LURb0whYduXA94gCg0BpG rrUKOuw1sr1kqvRDP6t1Aek= =MtPt -----END PGP SIGNATURE-----
participants (8)
-
Anthony Williams -
Emil Dotchevski -
Frank Mori Hess -
Frank Mori Hess -
Kowalke Oliver (QD IT PA AS) -
Peter Dimov -
Sebastian Redl -
vicente.botet