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

111–120 of 516 posts

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

#111

Post by erwincoumans »

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.

C is fine too. I pick a C++ subset that is closer to C than to full modern C++17. Full control over memory access, hardware access and execution. I haven't learned enough Rust yet, that could be fine too, but Rust lacks still many libraries in Robotics and Game development.

What else do you suggest?

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

#112

Post by ncmncm »

ModernMech wrote: post #84
pjmlp wrote: post #81

Earlier quoted context omitted.

My first contact with RAII was in 1993 with Turbo C++ 1.0, it is hardly a hot new thing.

That's not my point. The point is that this feature once was the hot new thing, and in the future there will be a hot new way to do the same thing in addition to all the old ways, because that's how C++ evolves. And I would have to say the average C++ dev did not know about RAII in 1993.

Destructors have been in C++ since the mid-80s. Anybody who did not know about RAII in 1993 did not know any C++.

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

#113

Post by jerf »

ModernMech wrote: post #51
nly wrote: post #6

Earlier quoted context omitted.

std::expected doesn't require language changes, it's a library type. If anything it shows how C++ is multi-paradigm

This is the great strength and weakness of C++. Increasingly the answer to C++'s rough edges is "We don't do things that way anymore. Everyone does X now", where X is the hot new thing. RAII is the best example I can think of, where some people insist that no one would ever use the "new" and "delete" keywords anymore. Except for all the C++ devs that do, and all the C++ code that exists that does and must be maintain…

I kinda look to when the thing finally stabilizes as a sign as to how bad the problem was. For instance, Javascript front end was a nightmare for a long time, but it seems to have finally stabilized into a reasonable stable configuration with a couple of winners, some minor specialized choices, and the endless churn is now a minor sideshow instead of something that is changing the default choice every six months. There was a bad problem there, but it seems to have been satisfactorily conquered for now. (I expect as static typing creeps ever more deeply into the JS ecosystem that at some point that may cross a critical point and cause some more churn, but at least for now things seem more stable.)

While C++'s churn frequency seems to be higher than the Javascript front end churn frequency, as an outsider, it still seems like "best practices" on C++ are churning around 1.5-2 years, it's been happening for my entire career, and it's still happening. If I seem a bit unsympathetic to the claims that the problems are solved if you just write your C++ code this way now, it's because I first heard that in 1998 or so, for a set of common practices now considered laughably out of date, of course.

At some point it becomes more cost-effective to just "churn" on to Rust next time, because even though in that same time frame Rust is a younger language that was going through its early design iteration phase it still seems like it has settled into a lower-frequency churn rate lately for "best practices" than C++.

There's probably some interesting and deeply profound reason why C++ just can't seem to stabilize across what is approaching an entire human generation, but I'm nowhere near interested enough in learning it to actually learn the amount of C++ it would take to find it.

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

#114

Post by masklinn »

rr808 wrote: post #62
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.

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

Because that meshes so well with copy and move ctors, const and reference members, or inheritance.

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

#115

Post by synergy20 »

Rarebox wrote: post #53
synergy20 wrote: post #38

C++ STL is a strong selling point for c++, disabling exceptions mean you lose all of STL in the library, unless you're fine to use STL without any error reporting at all. 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…

There's very little you need exceptions for with STL. Data structures, algorithms, etc. all work just fine without exceptions. C++ without exceptions is great. Google doesn't use exceptions and they still use STL. Gamedevs usually don't use exceptions and they're fine. Just use some other mechanism for errors, like error codes, absl::Status, std::expected, etc.

Google did not do exceptions due to legacy code base reason, in its announcement it says for new code it will do exception, it just had too many old code and can't do exceptions.

Most STL operations and iteration etc will throw exception for errors, if you disable exception, any of those errors, be it recoverable or not, will just std::terminate, which might not be ideal.

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

#116

Post by jstimpfle »

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…

> Exceptions come naturally from the realization that you mostly have to propagate errors to where they can be suitably handled or logged.

I agree of course that errors must be handled and logged as appropriate, but the implication that this has to happen by popping from the call stack is not justified at all.

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

#118

Post by zozbot234 »

RcouF1uZ4gsC wrote: post #24

> It breaks the existing ABI, and all shared libraries would have to be compiled with the new model, as otherwise unwinding breaks. I am convinced that maintaining ABI is a huge technical debt to C++. And that is largely occasioned by shared libraries. Rust IMO made a fantastic decision to emphasize source distribution (and making it super easy via cargo and crates).

Rust just punts to the C ABI for shared libraries. Which is sensible since the whole point of those is to share code system-wide, and the C ABI is the de-facto common interface for "foreign" code on systems where shared libraries are widely deployed.

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

#119

Post by ncmncm »

rr808 wrote: post #62
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.

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

By "best" you mean, of course, "worst".

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

#120

Post by anarazel »

grandinj wrote: post #90

Counterpoint: I do a lot of perf work on LibreOffice, which makes extensive use of exceptions, and I have never ever even seen the exception throwing show up on a profile, let alone become a problem. I think this paper started with a conclusion, and worked backwards to justify it.

When I read the title, I was assuming it was going to be about worsened code generation when building with exception support. Not about, basically, throwing exceptions as fast as possible. That seems an odd concern given the current performance.
Post reply on HN