Re: [boost] [c++1] BOOST_NOEXCEPT macros?

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 http://lists.boost.org/Archives/boost/2011/02/177284.php 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
specification.

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.

--Beman