|
Boost : |
From: Daniel James (daniel_james_at_[hidden])
Date: 2008-07-02 07:51:05
2008/7/1 Emil Dotchevski <emil_at_[hidden]>:
> On Tue, Jul 1, 2008 at 1:53 PM, Daniel James <daniel_james_at_[hidden]> wrote:
>>
>> Exceptions seem to work in g++ with RTTI disabled.
>
> Catch needs to discriminate between different exception types in a way
> similar to dynamic_cast, except that unlike dynamic_cast, it needs to
> work for objects of non-polymorphic types as well. That's what I was
> referring to.
Sorry if my email wasn't very clear. I was just pointing out that
exceptions work with the -fno-rtti compile option, which is what
BOOST_NO_TYPEID supports. So disabling exceptions when it's defined
might be the wrong thing to do. The situation might be different for
other compilers. You'll know better than me.
>>> I think the best option is to #define BOOST_EXCEPTION_DISABLE if
>>> BOOST_NO_TYPEID is defined.
>>
>> This seems very disruptive. If that's the only solution then, at this
>> stage in the release cycle, it might be better to just leave things as
>> they are and live with the regression (it's for an undocumented
>> feature, so I don't think it's a show stopper).
>
> It seems pretty straight forward to me
But doesn't it change the behaviour of any library which uses your
library? That's why I said it seems disruptive.
> my only question was what's
> the right way to do this since I don't know much about configuring
> Boost.
Well, I'm no expert on this. I agree that if you've disabled
exceptions, you probably should define BOOST_DISABLE_EXCEPTIONS. If
someone uses it badly (checking for it in a header without first
including your headers) it could cause an ODR violation, but that's a
minor concern.
You could possibly have two separate macros - one user settable one
which tells Boost.Exception to disable exceptions, and one which
Boost.Exception sets when exceptions are disabled or aren't available.
But that's probably too complicated, no one would ever know which one
to use.
Also, looking at Boost.Config, there are user settable options to
which BOOST_DISABLE_EXCEPTIONS could be added (since it's fairly
universal):
Daniel
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk