On Tue, Jun 19, 2012 at 6:33 PM, Robert Ramey <ramey@rrsd.com> wrote:
Just look higher in the the thread for Emil's definition of BOOST_NO_EXCEPTIONS. This is different than the one in the documentation which has never changed and in fact is part of another library. This situation has lead to much confusion as to what this macro means as noted higher in the thread.
Maybe you're confused because you're looking for a change that doesn't exist? :) The semantics of the BOOST_NO_EXCEPTIONS configuration macro have not been changed. If it is defined, Boost Libraries must not throw exceptions. One way to do this was, and still is, to use boost::throw_exception to throw. You should be able to guess what happened.
All the librarires which has presumed the original operation started to have changed behavior. Longer build time, dependence on a new library, new requirement that the library be only used with rtti turned on.
I'm sorry but you'll have to back the "longer build time" claim with hard data. You're factually wrong about RTTI, it doesn't have to be turned on. others had to creat their own macros to implement the behavior of the
original boost::throw_exception. So now we have the case where
That's also wrong, nobody had to do anything. Not only it didn't break any library, it caught bugs in libraries that called boost::throw_exception with types that don't derive from std::exception (in violation of its requirements.)
a) the original functionality is not found in boost, anyone who needs it has to implement it on their own.
I'd like to see an example of a program that works with what you call "the original functionality" but doesn't work with the official boost::throw_exception. Basically, if one want's the functionality of boost exeception, he should
#include <boost/exception/thow_exception.hpp> .. boost::exception::throw_exception
and if he want's the original behavior he should be able to say
#include <boost/throw_exception.hpp> ... boost::throw_exception.
This would work only for exceptions emitted by user code. Boost Exception is quite useful (to the user) for exceptions that originate in library code. gratuitiously changing the behavior of a long standing function in the
boost core which other library depend on is an unfriendly practice. I know Emil is convinced that he's done us a big favor by forcing us to convert to behavior which he knows is better for us, But it's not his call to make.
No it wasn't my call obviously. Boost Exception was admitted by the usual review process.
(For the record, I've glanced at the blurbs on BOOST_NO_EXCEPTIONS within Boost.Config and Boost.Exception and it's difficult for me to parse what effect their differences have in practice, and it sounds like others have a good idea what the problem seems to be.)
You'd be able to make a better argument for your case if you understand how boost::throw_exception was changed (it's been what, 4 years ago now?) That change boils down to inserting class boost::exception, which does not implement any functionality, as a base. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode