Re: Is there a good use case for noexcept?
On Apr 24, 4:07 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
Alexander Terekhov <terek...@web.de> writes in comp.lang.c++.moderated:
DeMarcus wrote:
[...]
The problem is that stack exhaustion (out-of-stack-memory)
is also a failure, so even the simple function std::swap may
fail.
Exactly! And the runtime behaviour should be the same as with
int f() { // implicit nothrow/noexcept
throw 0;
}
No?
C'mon, a noexcept function shall call abort() (C++
terminate()) on throw / stack exhaustion.
Stack exhaustion is undefined behavior in C++. Mainly because
C++ generates and executes native code, and in native code,
stack exhaustion is handled by the OS; there's nothing the
generated code can do to trap it, or even to detect it.
A libraryable function should return control to its caller
whenever possible. And usually, an exhausted stack will be
relieved more by returning than by calling.
:-) Usually, an exhausted stack will either result in a core
dump, or overwriting memory that isn't part of the stack. (The
latter can easily occur in multithreaded environments, if the
stack for each thread is allocated in the general free store.)
I also wonder whether you suggest that every (noexecept)
function should always check explicitly for stack exhaustion
and try to specify a behavior for this.
It would be nice, if it were possible.
Is anyone here who uses =BBabort()=AB at all?
Anyone developing critical applications. And probably a lot of
others.
I assume nearly all the programs we write operate under the
=BBoptimistic=AB assumption that there always is enough stack,
while at the same time try to avoid being too careless about
it, that is, trying to avoid deep recursion and so.
Agreed. Along with a couple of other optimistic assumptions:
there will be enough memory, an int won't overflow, etc.
Ideally, we'd like 1) to be able to validate our assumptions up
front (usually possible for int overflowing, not so easy for the
other cases), and 2) have the program fail immediately if the
assumption fails.
This might be not good enough for high-security
applications, where one would like to have some call like
=BBsize_t autostorage()=AB that gives the amount of automatic
storage still available.
One would like a lot of things. One doesn't always get them:-).
--
James Kanze