The problem is elimination of exception handling from generated code.
In practice, it's not hard to know that a particular zone is a no-
throw one. If performance is critical, it might be desirable to shed
any overhead in places, including "I swear, it will be unused"
exception handling.
But in practice, compiler can't know whether some part is a no-throw,
for various reasons. It would have been nice if it could, but...
Therefore, I see no problem in implementations allowing such "no-
throw" zones in code.
That said, I am 100% with you on a related notion there's no C++
without exceptions.
A necessary but sad state of affairs, I agree.
Ideally, this would be mostly unnecessary because exception handling
would basically carry zero runtime overhead for the not-thrown
execution path. The good and intended implementation of exceptions is
the out-of-line table approach. With that, there is no extra
instructions which must be executed in a function with a throw
statement or try block. There is overhead in terms of a larger
executable, but with virtual memory, this carries no additional memory
requirements (though perhaps a larger swap size). Also, if the
compiler and linker put the exceptions tables into a different virtual
page in the executable or shared lib, then this carries basically no
runtime speed cost at all.
Without virtual memory and sufficient swap size, then yes I agree it
could be a problem, in which case it would be very useful for a
compiler to optimize away exception table entries for regions of code
which cannot throw. However, if this is a concern, if there isn't
virtual memory, then I would hazard a guess that you've already turned
off exception support or are using C.
Moreover, I think C++ has really suffered as a language because of
this. Sadly, half the major implementers of C++ missed the memo on
what exceptions were meant to be, and they implemented them in such a
way that a try block or the presence of a throw exception incurs
runtime speed costs even on the no-exception-thrown execution paths.
Because of this, those rabidly concerned with speed do not use
exceptions in performance critical code, and once you lose exceptions,
you lose a major part of C++.
First, exceptions are a very useful way to signal rare and unlikely
fatal-ish errors. Second, without exceptions, constructors cannot
signal failure, so a large portion of objects must have a zombie
state, there must be a separate init function which does the work of
construction. Either way, it's much more tedious. Example:
foo f(some args); //might throw std::bad_alloc
f.a(); //might throw std::bad_alloc
f.b(); //might throw std::bad_alloc
f.c(); //might throw std::bad_alloc
return f;
vs the common:
foo f;
if (COMPANY_PREFIX_SUCCESS != f.init(some args))
return COMPANY_PREFIX_FAILURE;
if (COMPANY_PREFIX_SUCCESS != f.a())
return COMPANY_PREFIX_FAILURE;
if (COMPANY_PREFIX_SUCCESS != f.b())
return COMPANY_PREFIX_FAILURE;
if (COMPANY_PREFIX_SUCCESS != f.c())
return COMPANY_PREFIX_FAILURE;
return f;
vs the common way to make this more bearable with macros:
foo f;
COMPANY_PREFIX_HANDLE_FAILURE(f.init(some args));
COMPANY_PREFIX_HANDLE_FAILURE(f.a());
COMPANY_PREFIX_HANDLE_FAILURE(f.b());
COMPANY_PREFIX_HANDLE_FAILURE(f.c());
return f;
Without exceptions, we're left with a very C way of doing things.
Every nontrivial function must have its return value be an error code.
It's more boileplate code, so it's tedious on the programmer, it's
more error prone for the programmer, it takes longer for the
programmer to write, and it takes longer for another programmer to
read, so it's worse for maintenance as well.
Finally, proper use of exceptions on a proper implementation results
in faster code than the C way of error return codes. Each error return
code requires a branch, which at worst stalls the pipeline, and at
best takes up a spot in the instruction pipeline, instruction cache,
and other such things. On the no-throw execution path, the (usually
very) common path, code using exceptions does not have this extra
usually-useless instruction in-line, which means it's slightly
faster.
PS: I've posted this three times now. Let's see if it finally takes it
this time.