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

141–150 of 516 posts

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

#141

Post by ncmncm »

masklinn wrote: post #132
pjmlp wrote: post #109

Earlier quoted context omitted.

C++ is the only language where exceptions are such an ideology war. All the other ones that have born with exceptions don't have this issue, including Ada.

I'm not sure that's true. Exceptions are a big issue in Javascript, though mostly because they're absolutely terrible. Whether to use exceptions or not is a common question in e.g. C#, and several APIs are duplicated to have both exception-based and values-based variants. And Python is oft criticised for using exceptions more than once every blue moon.

No legitimate conclusions can be drawn from Java or C# experience, besides that it is best to stay well clear of them.

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

#142

Post by JAlexoid »

jerf wrote: post #113
ModernMech wrote: post #51

Earlier quoted context omitted.

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. The…

One of the reasons why I try to avoid C++ is that it's an unopinionated multi paradigm kitchen sink language.

There are great uses and great features, but there are so many of them and everyone has their own opinions.... Even in this thread there's a clear subset of people who "adore" C++ exceptions

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

#143

Post by musingsole »

zozbot234 wrote: post #86
edflsafoiewq wrote: post #72

Earlier quoted context omitted.

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. The…

> They generate syntactic noise at every point they touch the call graph: function signatures, calls, returns. This is not "noise" but needed information. A function that can error out should not have the same signature as one that will never return an error. Similarly, call-site special syntax (like '?' in Rust) helps address the concerns raised by hidden control flow. > Since the caller must be aware of them, gener…

> one that will never return an error

Code that is error-safe is so rare. Why adopt a pattern that elevates the normal case ("here be errors") to information you have to disclose at every turn?

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

#144

Post by kaetemi »

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.

Gamedevs usually don't handle any errors at all.

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

#145

Post by pjmlp »

masklinn wrote: post #132
pjmlp wrote: post #109

Earlier quoted context omitted.

C++ is the only language where exceptions are such an ideology war. All the other ones that have born with exceptions don't have this issue, including Ada.

I'm not sure that's true. Exceptions are a big issue in Javascript, though mostly because they're absolutely terrible. Whether to use exceptions or not is a common question in e.g. C#, and several APIs are duplicated to have both exception-based and values-based variants. And Python is oft criticised for using exceptions more than once every blue moon.

It is a big difference to offer both kinds of APIs, or to make endless flamewars with compiler runtime forks, which is what disabling exceptions and RTTI mean in practice, a fork from ISO C++.

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

#146

Post by JAlexoid »

Koshkin wrote: post #125
jerf wrote: post #113

Earlier quoted context omitted.

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. The…

> C++ just can't seem to stabilize It's not like C++ is oscillating. It continues to improve, which is a good thing.

Adding more and more features isn't necessarily an "improvement".

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

#147

Post by Koshkin »

ncmncm wrote: post #133
erwincoumans wrote: post #111

Earlier quoted context omitted.

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?

In other words, you pick exclusively the worst features of C++, and ignore all the actually useful, helpful features that enable you to write better code. If you just want C, use C.

Well, with a C++ compiler there's always hope that they will pick up the good parts, eventually.

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

#148

Post by tneumann »

ziml77 wrote: post #34

I find this analysis strange. Yes, C++ does need ergonomic ways to return an error without dynamic allocation (Rust's magic of ? combined with the From/Into traits is nice), but I don't know why you'd analyze the performance impact when you have many failures. If a failure is that common, then you aren't supposed to be using exceptions. It's not really an exceptional circumstance at that point.

That argument is only true in single threaded applications, at least given today's exception implementations. The more threads you have, the more problematic exceptions become. On the large machine you start to see performance problems with 0.1% failure rate, which is not that much. An core counts continue to rise.

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

#149

Post by brundolf »

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.

It probably depends a whole lot on whether exceptions are used only for exceptions, or for control-flow. The author seemed to be treating this question fairly pessimistically

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

#150

Post by exdsq »

edflsafoiewq wrote: post #72
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. The…

An FYI that Monads are useful for removing that (left, right) boilerplate from composed functions. This was the issue I had where they finally clicked for me.
Post reply on HN