Daniel James wrote:
On 19 June 2012 18:11, Robert Ramey <ramey@rrsd.com> wrote:
According to http://www.boost.org/doc/libs/1_49_0/libs/config/doc/html/boost_config/boost...
"The compiler does not support exception handling (this setting is typically required by many C++ compilers for embedded platforms). Note that there is no requirement for boost libraries to honor this configuration setting - indeed doing so may be impossible in some cases. Those libraries that do honor this will typically abort if a critical error occurs - you have been warned!"
a) This definition is in the current and all past documentation and should be respected by all code which uses the macro BOOST_NO_EXCEPTIONS
From http://www.boost.org/doc/libs/1_31_0/libs/utility/throw_exception.html
"It is intended to be used in Boost libraries that need to throw exceptions, but support configurations and platforms where exceptions aren't available, as indicated by the presence of the BOOST_NO_EXCEPTIONS configuration macro."
Suggests that the config documentation isn't in line with how it's been used for the past nine years.
b) boost::throw_exception should be rolled back to it's orginal meaning.
Reason:The problem here is that using something from the main boost namespace creates and unexpected and hidden dependency on another library. This occcurs without the library user getting notified at all. Much care has been expended so that those things directly inside the boost namespace (excluding convenience headers) be things which DO NOT create dependencies on other libraries. The current definition of boost::throw_exception is the only exception to this.
That's an odd claim to make. Look at: boost::any, boost::array, boost::bimap etc.
OK - maybe I should phrase this more carefully. I don't think that something I include from /boost - (other than a convenience header) should depend on something more specific like boost/exception, boost/serialization or whatever. (Nor do I think that anything not in boost/ should be bart of the namespace boost: but rather in in boost::library_name:: ); Of course a number of older libraries like any, array, etc violate this idea. I presume that when boost was small it didn't matter and no one likely expected that boost would become as large as it has. And some more recent libraries e.g. boost.range also violate this by putting stuff directly in the boost namespace. The fact that this occurs doesn't convince me that it's a good idea. Basically I want to be including what I expect to include and not include what I'm not expecting to include. I would like to know that if I use #include <boost/foreach.hpp> I'm not including anything outside of the the boost directory and namespace. 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. Of course if I include <boost/archive/binary_oarchive.hpp> I can expect to include a bunch of other stuff and double check accordingly. And this one of my main complaints about the implementation of boost.exception. 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. 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.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost