Boost logo

Boost :

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


Daniel James wrote:
> On 19 June 2012 18:11, Robert Ramey <ramey_at_[hidden]> wrote:
>>
>> According to
>> http://www.boost.org/doc/libs/1_49_0/libs/config/doc/html/boost_config/boost_macro_reference.html#boost_config.boost_macro_reference.macros_that_describe_c__03_defects
>>
>> "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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk