Re:Current hardware trends make C++ exceptions harder to jus...
by tneumann on Tuesday February 22, 2022 @02:47PM
(#30432707)
Of course the fib example is extreme. But some code bases do a lot of calls, and people care about calling overhead. I think a moderate calling overhead like, e.g., with Herbecptions is acceptable, because usually people doing something useful in a function that will mask the calling overhead. But other approaches are really to expensive to justify, they violate the zero-overhead promise of C++.
Re:Current hardware trends make C++ exceptions harder to jus...
by fpoling on Tuesday February 22, 2022 @01:55PM
(#30431953)
It is not trivial in practice to make code safe in presence of exceptions even if one follows the best C++ practices. The errors can be very subtle and hard to identify. It is another reason besides the performance and code bloat why Chromium disables them.
People need to stop making trivial benchmarks and draw ... silly ... conclusions.
http://www.eecs.northwestern.edu/~robby/courses/322-2013-spr...
It is a fact that C++ exceptions are largely low overhead, and that you also don't have to use them. In fact, C++ can make everyone happy, because you can choose which parts you like.
Personally, knowing how exceptions are implemented and having implemented small parts of the ABI, I can safely say that I will be using exceptions where appropriate in all my C++ projects. Parts where real-time behavior is needed we can use custom containers that don't randomly exit on failure. On low-memory hardware it is beneficial to have either tiny exception footprint or no exceptions at all.
It is true that C++ exceptions as they are implemented can be improved upon, breaking ABI. There are also other contenders (Herbceptions) that show great promise, bringing another way of handling exceptions that is not source compatible. Either way, many who work with custom C++ code do not care much about ABI, as everything is source compiled, and such would benefit from a new ABI generation.
Zero-overhead exceptions by Herb Sutter: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p070...