31–40 of 516 posts
I always avoid C++ exceptions, and also try to avoid dynamic memory allocations, smart pointers and RTTI etc whenever possible. This is pretty common in latency and (pseudo) real-time performance critical work, such as robotics control and 3d gaming.
Curious as to the decision criteria.
If not exception, then how to fail constructor?
> As illustrational example consider this small code fragment: Consider this crap small code fragment. Any function that returns void is almost certainly wrong.
Very interesting that exceptions have much less overhead on the happy path than Rust/Haskell style Either types (std::expected): > For fib we see a slowdown of approx. 60% compared to traditional exceptions, which is still problematic.
Why do we need to have ambient control flow? This is what exception handling is, it's a hidden control flow. I don't use them. I just create an error type and pass that around. The only legitimate exception I will accept is when you access invalid memory. That's a special case and depending on the environment something extraordinary must happen. But exceptions and exception handling just creates annoying code. It doe…
There are some kinds of errors that can’t be handled locally, but do need to be handled globally, or generically higher in the call chain. Continuing execution after the error occurs will make the problem worse. Exceptions allow you to cease execution without putting an if statement after every function call.
Very interesting that exceptions have much less overhead on the happy path than Rust/Haskell style Either types (std::expected): > For fib we see a slowdown of approx. 60% compared to traditional exceptions, which is still problematic.
I'm not convinced a recursive implementation of `fib` is a reasonable example to draw such a conclusion.
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...
In the gaming case(no rtti, no smart pointer, no exceptions(thus meaning ctor|dtor are "unsafe")), what else do you leave with c++ then?
I use c++ but I'm always struggling with yes-or-no for exceptions.
c++ is deeply rooted with exceptions, bad or good.
If not exception, then how to fail constructor?
But returning null is an obvious choice.
Combined types which return the structure or an error are another. Has the advantage of returning error information, why failure.
There are many ways
Why do we need to have ambient control flow? This is what exception handling is, it's a hidden control flow. I don't use them. I just create an error type and pass that around. The only legitimate exception I will accept is when you access invalid memory. That's a special case and depending on the environment something extraordinary must happen. But exceptions and exception handling just creates annoying code. It doe…
With "exceptional" errors are are only 2 real recovery options: restart the operation or terminate the operation. Neither of these are typically decided on anywhere where an error might occur in the call stack.