Boost logo

Boost :

Subject: Re: [boost] [c++1] BOOST_NOEXCEPT macros?
From: Beman Dawes (bdawes_at_[hidden])
Date: 2011-10-11 07:54:30

On Tue, Oct 11, 2011 at 5:42 AM, Domagoj Saric
<domagoj.saric_at_[hidden]> wrote:
> On 10.10.2011. 17:55, Beman Dawes wrote:
>> On Mon, Oct 10, 2011 at 4:52 AM, Domagoj Saric
>> <domagoj.saric_at_[hidden]>  wrote:
>>> Didn't find that thread so I apologize if it was already discussed
>> See and replies.
>>> couldn't you add compiler specific versions [e.g. __declspec( nothrow ),
>>> __attribute(( nothrow ))...] for the non predicate/expression version?
>> That thread discussed the possibility of the C++03 version using
>> throw() for MSVC and __attribute__((nothrow)) for GCC.
>> The uses I'm making of it are for cases where there is nothing in the
>> current code, and the docs say "Throws: Nothing".
>> I guess we could provide yet another form that handled the
>> BOOST_NOEXCEPT_OR_EMPTY_THROWS case, but I'm not greatly interested in
>> working that one out. If someone else wants to take that on, fine.
>> Hopefully a shorter name could be found. Maybe BOOST_NEVER_THROWS.
> I found that thread but it didn't actually mention/discuss any problems with
> the compiler specific replacements so I thought you meant some other
> thread...

Here is the brief exchange I was referring too:

>Alexander Fokin:
> I believe it's not that simple.
> As I remember, throw() means the same thing as nothrow only in MSVC.
> For example, under GCC you'll have to use __attribute__((nothrow)).
> Correct me if I'm wrong.

Dave Abrahams:
>You're right. In general, throw() has runtime semantics and can
>produce runtime overhead in the form of increased executable size and
>occasionally reduced speed. ...

Continuing my reply to Domagoj,
> I must I don't understand why would using the mentioned compiler specifics
> require a different macro? AFAICT these are just different keywords that say
> the same thing to the compiler and the user (unless someone is actually
> worried by the fact that MSVC will not call std::unexpected/terminate in
> case you violate the promise you made about the function in question?)

Good question. There are two cases:

(1) For C++03 compilers, the macro user wants the mentioned compiler
specifics. That's the case an additional macro is needed for.

(2) For C++03 compilers, the macro user wants nothing inserted. That's
the case covered by the macros I've added to trunk. This case arises
because a lot of existing code isn't decorated with either throw() or
a compiler specific attribute, and the user doesn't want to add that
now. In applying noexcept to the standard library, this was by far the
most common situation encountered - there was no existing exception

Note that cases (1) and (2) may be interleaved in the same translation
unit, so using a config macro to specify the behavior won't work well,
and isn't a preferred approach anyhow.


Boost list run by bdawes at, gregod at, cpdaniel at, john at