On 11.10.2011. 13:54, Beman Dawes wrote:
On Tue, Oct 11, 2011 at 5:42 AM, Domagoj Saric <domagoj.saric@littleendian.com> wrote:
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.
I must say I still don't see why (1) would require an additional macro because I don't see why (2) would be required/wanted at all..? IOW why would someone want noexcept but not __attribute__(( nothrow ))? ps. except, as said previously, if there is a real world person/problem that depends on the defined std::unexpected/std::terminate behaviour of noexcept as opposed to undefined or implementation defined behaviour of a compiler specific in case "someone violates a promise given about the particular function"... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman