Re: Using noexcept
the compiler would still have to generate code to test
whether an exception is trying to leave the function,
and then call std::terminate,
True. the problematic case is when the throw can be potentially masked
by outer catch.
For example:
try {
function_with_noexcept();
might_throw();
extern_c_function();
}
catch(...) {}
extern-c function (e.g. OS call) might not be aware about the noexcept
state-flag hence it's the caller's responsibility to toggle the flag
before/after calling into every throw/nothrow (might skip some).
I personally wanted UB to push such bug handling under QOI but it
seems that the committee though that UB for such unhandled exceptions
is somewhat bad PR for a language. OTOH, mandating mitigation for such
specific bug seems inconsistent with other cases that traditionally
are left for UB (e.g. access bogus memory).
I also had no problem with breaking the legacy throw() requirement on
violation since the popular MSVC compiler is doing that since always
(hence favoring optimizations).
whereas if I had *no* exception specification,
no such code would have to be generated in first place *at all*.
IOW, you get less optimal code by adding "noexcept" -
This is not true. The compiler can avoid generating unwind code for
the throwing case which is the main no-throw optimization (caller and
callee). for example:
unique_ptr<A> p = new A;
nothrow_call(p);
// implicitly generate delete p, no need for special unwind on-throw
code
return;
so in which sense is this an improvement?
The nexcept(condition) is important for no-throw based user
optimization (e.g. move if no-throw).
I would also have understood if noexcept would be statically checked
since then I had means to validate at compile time
Static validation is problematic in general due to conditional no-
throw functions (runtime).
For example:
vector<int> v(10); // reserve space for 10 elements
v.push_back(1); // no-throw since no allocation needed
map<int, int> m;
m[0] = 0;
m[0] = 1; // no-throw on replace
It seems that for static checking, noexcept needs to have another
flavor - "unconditionally might throw".
This is probably much more common than conditional no-throw, For
example:
void* operator new(size_t) noexcept(--);
void foo() noexcept
{
new A; // can be statically rejected
}
Note that the MSVC compiler issues a warning when explicit 'throw' is
used unguarded inside a throw() function.
The above non-standard idea extends such for other functions beside of
the 'throw' operator.
One concern about having such is with breaking the compilation of lots
of existing code that doesn't care about conditions such as out of
memory.
I think that static checking is nice to have but not super crucial
since anyway proper testing is needed given the many other bugs that
can be detected only at runtime or using custom static analysis tools
(e.g. all the traditional UB bugs).
Rani
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]