Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Current hardware trends make C++ exceptions harder to justify

open-std.org

Post reply on HN
Print view View original

61–70 of 516 posts

Re: Current hardware trends make C++ exceptions harder to justify

#61

Post by mikepurvis »

masklinn wrote: post #41
john567 wrote: post #27

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…

One of the core problems is C++’s design basically requires it: there’s no other way to error from a ctor, and since ctors are used as hooks in many operations the dishonest rejoinder of “just use a factory” doesn’t work in any capacity.

Doesn’t some of the reliance on constructors for everything come from how constness is fetishized in C++? Not that it's all bad to have those checks in place, but Python doesn't have this issue with out of control constructors in part because (almost) everything in Python is just unapologetically mutable.

Re: Current hardware trends make C++ exceptions harder to justify

#62

Post by rr808 »

masklinn wrote: post #41
john567 wrote: post #27

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…

One of the core problems is C++’s design basically requires it: there’s no other way to error from a ctor, and since ctors are used as hooks in many operations the dishonest rejoinder of “just use a factory” doesn’t work in any capacity.

Best to create object then initialize it in a separate method.

Re: Current hardware trends make C++ exceptions harder to justify

#63

Post by _0w8t »

fwsgonzo wrote: post #37
yakkityyak wrote: post #19

Earlier quoted context omitted.

I'm not convinced a recursive implementation of `fib` is a reasonable example to draw such a conclusion.

It really isn't. 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…

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.

Re: Current hardware trends make C++ exceptions harder to justify

#64

Post by freedomben »

worik wrote: post #44

Begs the question: Why C++? Legacy projects (I am not being pejorative, they are important) which must be maintained aside, should not C++ be deprecated? We have many new languages, we always had C. What does C++ give us in 2022 that makes up for the enormous cognitive load of understanding and keeping up with it.

C++ is still a wonderfully performant language, and there are still domains where it is clearly a leader (networking, games/graphics, etc). Rust is slowly displacing it but there's still a lot of road left. The maturity, stability, prior art are also worth something. The pitfalls are really not that big and dangerous, although to someone who doesn't do C++ I can see why it has that perception. Additionally, if you aren't a functional programming lover (like I've become lately), C++ is one of the funnest languages to work in (as long as the codebase follows could principles).

That said while I used to use C++ for nearly everything, these days I use Elixir for app dev whenever I can, and Ruby and bash for scripts. However if I were going to write a desktop app today I'd most likely go for C++ so I could use Qt. I do really need to try out new GTK though, sounds like it's gotten really great.

Re: Current hardware trends make C++ exceptions harder to justify

#65

Post by WkndTriathlete »

jdlshore wrote: post #30
john567 wrote: post #27

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.

Haskell's IO monad says, "Hi! With me you don't need exceptions and you don't need to put an if statement after every function call."

Re: Current hardware trends make C++ exceptions harder to justify

#66

Post by physicsguy »

worik wrote: post #44

Begs the question: Why C++? Legacy projects (I am not being pejorative, they are important) which must be maintained aside, should not C++ be deprecated? We have many new languages, we always had C. What does C++ give us in 2022 that makes up for the enormous cognitive load of understanding and keeping up with it.

If you don’t want to use LLVM then you don’t have much choice.

Re: Current hardware trends make C++ exceptions harder to justify

#67

Post by _b »

rossmohax wrote: post #20

If not exception, then how to fail constructor?

Don't write constructors that can fail unless it is failure that would be appropriate to crash for. That works out a lot better than it might naively sound. It is hard for people to reason about the possibility of constructors/destructors failing, so actually rather nice to just forbid it.

Re: Current hardware trends make C++ exceptions harder to justify

#68

Post by mort96 »

wvenable wrote: post #40
john567 wrote: post #27

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…

Exceptions come naturally from the realization that you mostly have to propagate errors to where they can be suitably handled or logged. And all that propagation code heavily detracts from the meaning of the code when you are writing it or reading it. And messing up the propagation is a common source of issues (historically). With "exceptional" errors are are only 2 real recovery options: restart the operation or ter…

I also have to imagine there's a decent performance boost. With Rust's and Go's (and C's, usually) approach of having 'if (error) { return error; }' all over the place (with syntax sugar or not), there will be a lot of extra branches in the happy path. Sure, those branches are predictable and thus fast, but they're not instant, and they take up icache space in the happy path. Modern exception implementations can almost exclusively slow down the exceptional code, and code which propagates exceptions without catching or throwing will look identical to code with no error handling at all.

I'm sure the gains aren't tremendous, but lots of C++ design decisions are for slight performance improvements at the cost of less safety. Other examples are unchecked array access by default and unchecked overflow. Whether these are the right decisions or not is debatable, but at least it's consistent.

EDIT: Of course, as the article points out, if you have a high error frequency and many cores, exceptions cause significant performance issues. But in the case where exceptions are _actually_ exceptional, and especially in cases where the only real response to an exception is to log an error and exit, exceptions are exceptionally good (pardon the pun) from a performance perspective.

Re: Current hardware trends make C++ exceptions harder to justify

#69

Post by addaon »

worik wrote: post #31
erwincoumans wrote: post #23

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.

Why do you use C++ in those domains? Curious as to the decision criteria.

I work in the same domains, plus hard embedded real-time. Some projects end up choosing C, some C++. C has the advantage of simplicity and more mature tooling, C++ has the advantage of a stronger type system (able to move some things from correct-by-testing to correct-by-construction) and a medium-weight code generation system in the form of templates.

Re: Current hardware trends make C++ exceptions harder to justify

#70

Post by trimbo »

kirbyfan64sos wrote: post #43
jkaptur wrote: post #17

Earlier quoted context omitted.

I'm relatively new to C++ and I found absl::StatusOr and its helper macros to be extraordinarily pleasant.

It has helper macros now? I liked StatusOr but had to write my own helper macros for it at the time.

Ex: https://google.github.io/or-tools/cpp/status__macros_8h_sour...
Post reply on HN