Another way of saying this is that the stuff directly in boost/ is sort of "core boost" and including this stuff doesn't include anything outside of this "core". Thus, when I write my code - then I know what I'm getting.
Well maybe the extended throw info that Boost.Exception provides *is* core boost?
I include something <boost/throw_exception> and I get a whole layer of stuff I didn't ask for. It makes my job and everyone else harder than it has to be.
Sure, but it's a pretty small lightweight layer of stuff. I'd be very surprised if it's presence/absence could be detected in build times.
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.
It hasn't changed - BOOST_NO_EXCEPTIONS means "no exception handling support is available in the compiler - so don't use exceptions anywhere". When defined the Boost.Exception code doesn't even get #included. And while I realize that *you* may not have been looking when this change happened, remember that Boost.Exception (including this change) was reviewed, and as I recall got a lot of discussion. BTW there is a macro - BOOST_EXCEPTION_DISABLE - which disables use of Boost.Exception and reverts back to original boost/throw_exception.hpp behavior. Of course that's a global change which can't be used on a library-by-library basis. But frankly, I would prefer it if all libraries were on the same page here and all used BOOST_THROW_EXCETION consistently. Just my 2c... John.