Re: [boost] question re BOOST_NO_EXCEPTION

On 10/25/19 4:25 AM, Peter Bartlett via Boost wrote:

On Thu, 24 Oct 2019 at 17:47, Robert Ramey via Boost 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