Re: How on earth did noexcept get through the standards process?
On Mar 16, 2:42 pm, itaj sherman <itajsher...@gmail.com> wrote:
On Mar 16, 4:34 am, James Kanze <james.ka...@gmail.com> wrote:
On Mar 14, 11:31 pm, itaj sherman <itajsher...@gmail.com> wrote:
There are two main different kinds of "exception specification" for a
function:
1) "requests" - the programmer requests the compiler to verify that
the function applies to them (in some certain defined ways at compile
and/or runtime).
2) "promises" - the programmer promises that the function applies,
allowing the compiler to assume so for whatever it does (that can help
exception safety concept checking, and optimization).
The old specifications where of the first kind, and for
various reasons many people concluded they do more harm then
good (especially for performance critical languages).
Actually, the performance impact on most platforms was zero.
It was?
I mean, they compared code compiled with no-throw optimizations and
runtime checks to the same code with no-throw optimizations without
checks?
I mean, I compared code with no exception specifications with
code which had exception specifications, and found no
difference.
Then what makes 'noexcept' better than 'throw()' wrt performance? Is
it just the fact that the compiler knows no exception can be thrown
there (no user defined std::unexcpected can throw anything else and
demand continue execution)?
I don't know. If 'noexcept' gives the same guarantees as
throw(), then I don't see why it's better. About the only real
difference I see is that 'throw()' gives you the option to
specify some exceptions which might pass (and I can imagine that
causes a small performance loss in some special cases), and
noexcept doesn't.
Actually that makes sense. IMO, practically it still puts 'noexcept'
in what I callled 'promises' kind.
Both exception specifications (in C++) and noexcept are a
specification of a contract. It's up to the programmer to
respect the contract, or bad things will happen. Other
languages have tried to ensure statically that the contract was
respected, but in practice, that doesn't work too well; regard
the mess Java made of it.
I.e Instead the programmer promises
not to throw out of a noexcept function, he can do that, but he knows
the only consequence of it is that the program will end and there's
nothing he can do about it (unlike std::unexpected).
You can replaced std::terminate with your own function, and a
programmer wasn't allowed to do much except call std::terminate
in std::unexpected. (He could throw some other exception, which
was allowed, but in the case of 'throw()', no such other
exception exists. Otherwise, he must call terminate.)
These are practically the same. I still don't see why they
bothered to specify that and not just leave it undefined - but
if it doesn't hurt performance, an important benefit of
noexcept IMO, is still there.
Leave what undefined? (I've not read up on nothrow: if it
doesn't behave exactly like 'throw()', then I'm against it,
since the final behavior in the case of exception specifications
is one thing they got right---even if they aren't too useful
except when empty.)
--
James
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]