On Tue, Oct 11, 2011 at 5:42 AM, Domagoj Saric <domagoj.saric@littleendian.com> wrote:
On 10.10.2011. 17:55, Beman Dawes wrote:
On Mon, Oct 10, 2011 at 4:52 AM, Domagoj Saric <domagoj.saric@littleendian.com> 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