[numeric] Applying trivial bugfix
Hi, There are a lot of feature requests to support compilation with disabled exceptions #5731, #5076, #5393, #5800. Fix is trivial and well known: replace throw x; with BOOST_THROW_EXCEPTION(x); in a converter_policies.hpp file. But the library maintainer does not like BOOST_THROW_EXCEPTION because of code bloat. Can I apply another trivial fix: struct def_overflow_handler { void operator() ( range_check_result r ) // throw(negative_overflow,positive_overflow) { #ifndef BOOST_NO_EXCEPTIONS if ( r == cNegOverflow ) throw negative_overflow() ; else if ( r == cPosOverflow ) throw positive_overflow() ; #else if ( r == cNegOverflow ) ::boost::throw_exception(negative_overflow()) ; else if ( r == cPosOverflow ) ::boost::throw_exception(positive_overflow()) ; #endif } } ; Adding this will fix all the tickets and allow some of the dependent libraries to build with disabled exceptions. Boost.Lexical_cast tests will cover Boost.Numeric usage cases with disabled exceptions. Best regards, Antony Polukhin
If there will be no objections till the end of next weekend, i`ll commit the fix. Best regards, Antony Polukhin
Fix is trivial and well known: replace throw x; with BOOST_THROW_EXCEPTION(x); in a converter_policies.hpp file. But the library maintainer does not like BOOST_THROW_EXCEPTION because of code bloat. Perhaps what would be better would be to have a macro for "simple" exceptions that could be added in whatever file(s) BOOST_THROW_EXCEPTIONs definition exists (BOOST_THROW_SIMPLE_EXCEPTION? BOOST_THROW_UNMODIFIED_EXCEPTION? BOOST_THROW_RAW_EXCEPTION? not sure any of those names work). All if would do would throw the exception if exceptions are enabled or call the function otherwise - I'm sure this could be used in many other places and would avoid having an abundance of practically identical statement blocks.
Iain
Iain Denniston wrote:
Fix is trivial and well known: replace throw x; with BOOST_THROW_EXCEPTION(x); in a converter_policies.hpp file. But the library maintainer does not like BOOST_THROW_EXCEPTION because of code bloat. Perhaps what would be better would be to have a macro for "simple" exceptions that could be added in whatever file(s) BOOST_THROW_EXCEPTIONs definition exists (BOOST_THROW_SIMPLE_EXCEPTION? BOOST_THROW_UNMODIFIED_EXCEPTION? BOOST_THROW_RAW_EXCEPTION? not sure any of those names work). All if would do would throw the exception if exceptions are enabled or call the function otherwise - I'm sure this could be used in many other places and would avoid having an abundance of practically identical statement blocks.
That's the way it was originally. Then the implementation of BOOST_THROW_EXCEPTION got changed creating unexpected behavior and side effects in all the libraries which used. So... Maybe we can make BOOST_HANDLE_EXCEPTION to reinstall the initial behavior. However this time, it should only be writable in the SVN system by a strictly limited group of people who know that changing the implementation of something already in wide usage is not a good idea for lots of reasons. Robert Ramey
Iain
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Iain Denniston wrote:
Fix is trivial and well known: replace throw x; with BOOST_THROW_EXCEPTION(x); in a converter_policies.hpp file. But the library maintainer does not like BOOST_THROW_EXCEPTION because of code bloat. Perhaps what would be better would be to have a macro for "simple" exceptions that could be added in whatever file(s) BOOST_THROW_EXCEPTIONs definition exists (BOOST_THROW_SIMPLE_EXCEPTION? BOOST_THROW_UNMODIFIED_EXCEPTION? BOOST_THROW_RAW_EXCEPTION? not sure any of those names work). All if would do would throw the exception if exceptions are enabled or call the function otherwise - I'm sure this could be used in many other places and would avoid having an abundance of practically identical statement blocks. That's the way it was originally. Then the implementation of BOOST_THROW_EXCEPTION got changed creating unexpected behavior and side effects in all the libraries which used. So... I don't remember why this was done. We should never accept changes as
Le 28/02/12 18:16, Robert Ramey a écrit : this one.
Maybe we can make BOOST_HANDLE_EXCEPTION to reinstall the initial behavior. However this time, it should only be writable in the SVN system by a strictly limited group of people who know that changing the implementation of something already in wide usage is not a good idea for lots of reasons.
+1 for a simple macro that works as the initial version. Vicente
That's the way it was originally. Then the implementation of BOOST_THROW_EXCEPTION got changed creating unexpected behavior and side effects in all the libraries which used. So...
The thought of a new BOOST_HANDLE_EXCEPTION macro named "for historical reasons" pains me. :( Would it not then be a better idea to roll back to the old functionality and have an additional macro (BOOST_THROW_EXTENDED_EXCEPTION?) to provide the extended functionality the current macro provides? This is probably how such a library would have been created if done now and restoring what library authors intended seems like a good idea, plus if new users of the current macro are not happy with it, then I suspect some of those who have had it changed under their feet will be similarly unhappy (though perhaps unaware). I realise that given the macro is used widely through boost, changing it is not something to be done lightly, but since this would effectively be restoring previous functionality I don't see it as such an issue. Additional configuration options to make BOOST_THROW_EXCEPTION == BOOST_THROW_EXTENDED_EXCEPTION and vice versa would allow users to make a decision if the extra information is important to them and allow others to avoid the costs when required (also this would provide complete backwards compatibility with the current setup). Library authors could make an initial call (based on the type of library), users make the final decision. Whatever the final decision, I'd at least like to see the option to make all exceptions of one type or the other. Iain
2012/2/28 Iain Denniston <iain.denniston@gmail.com>:
Would it not then be a better idea to roll back to the old functionality and have an additional macro (BOOST_THROW_EXTENDED_EXCEPTION?) to provide the extended functionality the current macro provides?
+1
Additional configuration options to make BOOST_THROW_EXCEPTION == BOOST_THROW_EXTENDED_EXCEPTION and vice versa would allow users to make a decision if the extra information is important to them and allow others to avoid the costs when required
+1 After that, I would propose to replace all the "throw x" in all the libraries with BOOST_THROW_EXCEPTION(x). This would close a lot of feature requests, provide better support for compilations with disabled exceptions and improve user control over the exceptions. Best regards, Antony Polukhin
Fix for numeric was committed to trunk in revision r77234 I`ll merge it to release branch, if there is no objections and it passes regression tests. Best regards, Antony Polukhin
participants (4)
-
Antony Polukhin -
Iain Denniston -
Robert Ramey -
Vicente J. Botet Escriba