On Tue, Jun 19, 2012 at 6:33 PM, Robert Ramey <ramey@rrsd.com> wrote:
Jeffrey Lee Hellrung, Jr. wrote:
On Tue, Jun 19, 2012 at 3:51 PM, Robert Ramey <ramey@rrsd.com> wrote: [...]
And of course I'm still smarting from having the BOOST_NO_EXCEPTIONS definition change while I wasn't looking to from what has always been documented in a way that makes some sense to something that I still dont' get.
So I stand behind my suggestions.
Sorry, I've only been glossing over this discussion. Can someone please clarify how BOOST_NO_EXCEPTIONS has changed,
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.
what specific change Robert (and possibly others) find troubling, and what practical consequences this has had or presently has?
Well, it's left me confused about what it's supposed to be.
Okay, Boost.Config says about BOOST_NO_EXCEPTIONS that "The compiler does not support exception handling...Note that there is no requirement for boost libraries to honor this configuration setting" while Boost.Exception says "This macro disables exception handling in Boost, forwarding all exceptions to a user-defined non-template version of boost::throw_exception<http://www.boost.org/doc/libs/1_49_0/libs/exception/doc/throw_exception.html> ." Is the confusion primarily that there are two descriptions of BOOST_NO_EXCEPTIONS? I certainly find this confusing, and it would be great if these descriptions can be brought more in line with one another. Is the confusion whether this applies to a property of the compiler (as Boost.Config suggests), or whether it is a user-defined setting (as one may infer from Boost.Exception's description)? From a library's point-of-view, I don't see any practical difference; if a library wants to support a defined BOOST_NO_EXCEPTIONS in either case, it can't have any exception handling code. Is the confusion whether respecting the disabling of exception handling is optional within a given library (as stated by Boost.Config) or mandatory, with any exceptions going to boost::throw_exception (as one may infer from Boost.Exception's description)? Except for the apparent requirement implied by Boost.Exception that all libraries will "throw" exceptions through boost::throw_exception when BOOST_NO_EXCEPTIONS is defined, these don't seem incompatible. If a library uses boost::throw_exception to "throw" exceptions, it likely will do so consistently, so will automatically support disabling exception handling. On the other hand, if it doesn't, well, it either doesn't support the disabling of exception handling or it uses its own mechanisms to deal with "exceptional" situations. I presume some libraries may take the latter approach? Meaning the assertion that all exceptions are forwarded to boost::throw_exception is inaccurate?
Ditto for boost::throw_exception.
Ahhh - a somewhat different case. boost throw exception as implemented in a very simple way for a very simple purpose. That purpose was to provide and escape to a global function which one could implement for those platoforms which failed to implement exceptions. This is not so uncommon for embedded systems and some shops which prohibit usage of exceptions.
Okay, I'm following.
The function of this was changed with the inclusion of boost.exception which altered the purpose and implementation of boost::exception in include the functionality of boost.exeption. You should be able to guess what happened. All the librarires which has presumed the original operation started to have changed behavior.
Okay, so I infer that, "before", "boost::throw_exception(e);" was equivalent to "throw e;"; "now", it is equivalent to "throw enable_current_exception(enable_error_info(e));". enable_error_info ensures the thrown object derives from boost::exception, while enable_current_exception "enables exception_ptr support". Okay, I admit, it's been a while since I've read the Boost.Exception docs and I forgot what that "exception_ptr support" means, but I think the point is that the actual thrown object is different "now" from "before". Although I think the idea was that the new thrown object still inherited publicly from the original object, so catch blocks should still function as before. Longer build time, dependence on a new library, new
requirement that the library be only used with rtti turned on.
At this point, based on Emil's and John's responses, it seems these first 2 issues aren't really problems in practice, while the 3rd issue is simply not the case. For some
unfathonable reason, the change in boost::throw_exception was allowed to stand. So these libraries including serialization, boost.filesystem, and some others had to creat their own macros to implement the behavior of the original boost::throw_exception.
Was actual code broken due to the change, and, if so, do you remember any examples? Or were those libraries authors who reimplemented the original functionality simply concerned with the overhead introduced by boost::throw_exception? So now we have the case where
a) the original functionality is not found in boost, anyone who needs it has to implement it on their own. b) the same functionality is re-implemented in several other libraries which required a new round of updating of code a documentation, c) and now we have the situation where a user who invokes something in the core boost - boost::throw_exception is likely to get a lot more than he bargained for.
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.
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. It's not for me to go around chaning the behavior of other peoples libraries just because I know better.
Okay, fair enough; this is an understandable but more philosophical point concerning development practices. At this point, though, boost::throw_exception has had these semantics since...well whenever Boost.Exception was released, which appears to be 1.36 based on my changing the version number in the URL of the documentation of boost::throw_exception :/ And it seems like changing it *back* to the pre-1.36 functionality would break more code than the change introduced in 1.36.
(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.)
I hope I clarified this.
Clearly not entirely :) - Jeff