Re: question re BOOST_NO_EXCEPTION

From: Robert Ramey (ramey_at_[hidden])
Date: 2019-10-25 14:57:08

On 10/25/19 4:25 AM, Peter Bartlett via Boost wrote:
> On Thu, 24 Oct 2019 at 17:47, Robert Ramey via Boost <boost_at_[hidden]>
> wrote:
>>>
>>> I want to detect whether or not the -no_exception compile time flag
>>> has been used on gcc/clang.  Will BOOST_NO_EXCEPTIONS do this?  If not
>>> is there something I can use?
>>
>> A look at the code or a simple Google search allows to answer these
> questions.
>> Boost.Config will define BOOST_NO_EXCEPTIONS if it is not already defined
> and it detects that the compiler has exceptions disabled.
> 
> Also, If you (Robert) would reverse your decision from 2009 and just let
> boost::serialization::throw_exception == boost::throw_exception rather than
> being a copy of the 2002-2009 version, then you won't have to think about
> these config things - the upstream library does it for you!

Hmmm - I'm not convinced that it does. I was surprised when the original 
definition of BOOST_THROW_EXCEPTION was altered from a very simple macro 
to put a common face on some inconsistencies between compilers with a 
full blown component with lots of new behavior that required a lot of 
investigation of it's implicatitions.  When it happened it broke my code 
and created all sorts of havoc. That was not a nice thing to do. 
Established definitions that others depend upon shouldn't be changed 
without notice.  Of course it came at a very inconvenient time for me so 
that didn't help.

I recently looked into the documentation of Boost.Exception and my 
conclusion was that I'd have to spend a lot of time looking into what it 
actually does and how it does it to know what the implications of using 
might be.  It certainly didn't shed any light on the current question.

> 
> It seems a bit glasshouses to tell a Boost.JSON to depend Boost.Sprit when

I don't think this is a good analogy.

> you yourself won't accept even this relatively trivial dependency on
> Boost.ThrowException :-)

LOL - "trivial dependency" - trivial is in the eye of the beholder.  It 
doesn't look trivial to me.  In the first "surprise package" iteration 
it added 5K lines of header code to every component which used it.  I 
understand that that has since been addressed.  But it illustrates the 
pitfall of injecting one's code into someone else's library without 
telling them just so you don't have to spend the time convincing them 
that it's a good thing.  I'm sympathetic - make a case for adding one's 
code takes work, but ambushing them is not a great substitute - it 
creates resentment and ultimately doesn't help you meet your goal.

> 
> Pete
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>