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

71–80 of 516 posts

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

#71

Post by trinovantes »

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.

I still use C++ for the occasional projects that a quick Python script can't easily solve

- I've been using C/C++ since my first year of undergrad so I'm already familiar/comfortable with it

- Java has too much boilerplate (my mind is still stuck in Java 8 so maybe things have changed since then)

- I found myself spending more time fighting the Rust/Go compiler than actually solving my problems

- I don't want to package a web browser for a simple 1-2 UI application

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

#72

Post by edflsafoiewq »

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…

My problems with Result/expected/etc

1. They generate syntactic noise at every point they touch the call graph: function signatures, calls, returns.

2. In particular, if a change causes a deeply nested function that used to always succeed to be able to error, the entire path up the call graph needs to get Resultified.

3. Since the caller must be aware of them, generic code generally has to be Result-aware too.

4. They aren't a total solution, exceptions usually have to exist anyway (eg panic), for things like oom/assert/etc. So you're usually paying the cost of them anyway.

5. You only get what the callee gives you. With exceptions, you can get a backtrace to the cause of the error by default, with no effort needed on the part of the callee.

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

#73

Post by CyberRabbi »

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.

> (pseudo) real-time performance critical work, such as robotics control and 3d gaming.

In reality all interactive applications are real-time performance critical. Any normal user would say that an unresponsive application is unacceptable. Sadly the entire stack of our contemporary desktop runtime environments grew out of background batch processing systems. This means that an application becoming unresponsive can be a sign of normal system operation.

Even if you avoid malloc, any memory access can trigger swapping which can block your main thread indeterminately. Or if you are running a high enough amount of CPU-hungry processes concurrently, your main thread can block indeterminately.

Millions of programmers carry on building applications for these systems blissfully unaware of these fundamental flaws. Application runtimes like Electron flourish, riddled with thousands of unbounded operations on every mouse click.

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

#74

Post by jmyeet »

jeffbee wrote: post #9
jmyeet wrote: post #3

> Root cause > Traditional C++ exceptions have two main problems: > 1) the exceptions are allocated in dynamic memory because of inheritance and because of non-local constructs like std::current_exception. This prevents basic optimizations like transforming a throw into a goto, because other parts of the program should be able to see that dynamically allocated exception object. And it causes problems with throwing ex…

You don't have to start over with the whole language. Just use -fno-exceptions in your project and dictate the use of std::optional, or absl::StatusOr, or whatever your favorite variant return type may be. For the examples in the article, it may be perfectly fine to not support failure, to simply std::abort whenever the sqrt of a non-positive is requested and rename the function sqrt_or_die.

Except if that's incompatible with libraries you're using.

For the record, I like absl::StatusOr.

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

#75

Post by addaon »

criddell wrote: post #60
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.

Believe it or not, there are a lot of us who enjoy C++ and think the language is getting better all the time. IMHO, it's a pretty good time to learn C++. As for what do you get? Well, compared to C you can get higher programmer productivity and compared to any language other than C, you get great performance.

I find that it's not rare to get better performance from C++ than C. As a trivial example, generic container code in C is likely to be run-time generic and sit on memcpy etc; the same functionality in idiomatic C++ is likely to be compile-time generic and be able to use fixed-size copy/move operations instead.

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

#76

Post by ska »

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.

> We have many new languages, we always had C.

The short answer is probably that (unsurprisingly) C still does not scratch the particular itches that C++ was created for, and non of the new languages hit all of them well either. Plus network effect.

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

#77

Post by addaon »

_b wrote: post #67
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.

And for those super-rare cases where it's appropriate to crash / fail hard in a constructor but you still have requirements about reporting or even recovery... setjmp/longjmp still exist.

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

#78

Post by burnished »

zabzonk wrote: post #26

> As illustrational example consider this small code fragment: Consider this crap small code fragment. Any function that returns void is almost certainly wrong.

What does 'wrong' mean in this context? I mean, if you're against side effects and thus believe functions should always return a value that seems reasonable. Except that for a toy example where the purpose is to exercise some hardware and measure results it does not seem to be applicable.

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

#79

Post by mjw1007 »

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 motivating examples for exceptions, at the time when they were beginning to appear in mainstream languages like Ada, was to allow people to write arithmetic expressions using familiar notation, while still having a place to put an error handler for the overflow case.

Perhaps the lesson of the last forty years or so is that this convenience wasn't worth adding such a heavyweight feature to the language, but it seems to me that modern languages are still weak at handling overflow.

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

#80

Post by chippiewill »

mikepurvis wrote: post #61
masklinn wrote: post #41

Earlier quoted context omitted.

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.

You could potentially argue that, but certainly Rust doesn't encounter this issue despite being const by default because they simply don't have constructors in the first place.
Post reply on HN