Re: [boost] Boost and exceptions

Subject: Re: [boost] Boost and exceptions
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-06-19 21:33:41

Jeffrey Lee Hellrung, Jr. wrote:
> On Tue, Jun 19, 2012 at 3:51 PM, Robert Ramey <ramey_at_[hidden]> 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