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.
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. 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. Longer build time, dependence on a new library, new requirement that the library be only used with rtti turned on. 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. 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.
(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. Robert Ramey
- Jeff
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost