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

81–90 of 516 posts

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

#81

Post by pjmlp »

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…

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

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

#82

Post by Koshkin »

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.

Little things... Destructors; overloading; namespaces; and yes, exceptions. Things I can no longer live without. Generics (templates) are nice to have, too.

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

#83

Post by _0w8t »

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.

Note Google explicitly configure runtime to instantly crash on memory allocation errors. With that STL works indeed nicely without exceptions.

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

#84

Post by ModernMech »

pjmlp wrote: post #81
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…

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.

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

#85

Post by mannykannot »

_0w8t wrote: post #42
rossmohax wrote: post #20

If not exception, then how to fail constructor?

Signal failure via an out parameter reference. For destructors store the reference in the object and call an error method on errors.

I think that would be problematical in those cases where the special constructors are called, and complicate using constructors in expressions and argument lists.

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

#86

Post by zozbot234 »

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…

> 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, generic code generally has to be Result-aware too.

True, but the Rust standard library includes a zero type that can be used to mark a Result-aware function as infallible, making it easy to wrap it with a non-Result type.

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

#87

Post by mikepurvis »

chippiewill wrote: post #80
mikepurvis wrote: post #61

Earlier quoted context omitted.

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.

Yeah I knew I was going to get called out with a Rust comparison. I think the Rust approach basically acknowledges the issue with what C++ did— that automatic initialization is cute but ultimately wasn't worth what it ended up costing in terms of hidden control flow, poor error handling, static initialization issues, etc.

Anyway, Rust basically deals with it by giving the class designer the choice to supply factory functions or punt on it, making the user initialize every field themselves each time. And I think most agree that this is a good approach; it's the best of C++ (factories) with a better fallback than a default constructor.

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

#88

Post by ithkuil »

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…

Not all errors are "exceptional". For example, consider an API that lets you open a file (local or remote); it may be very common that a file doesn't exist and it may be natural to handle that case by checking a "file not found" error (checking if the file exists before accessing it incurs in an extra cost and it's also racy).

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

#89

Post by duped »

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 think I agree with the sentiment but not the example, no one seriously advocates for no-new/no-delete (collections must still be written, somewhere) but rather that new/delete are generally code smell and there are idioms that can help isolate bugs. Part of maintaining old code is updating to those idioms.

But yea this kind of thing hit me recently on the interview circuit. I wrote some correct C++ (in that it was correct for the idioms in vogue when I last wrote C++ regularly for money) but I got feedback I wasn't as senior as they hoped due to my (lack of) C++ knowledge. Part of that was a shitty interviewer, but it's also just a fundamental part of the language. If you leave for a few years or try and change shops you find that everything under you has been removed or a completely different subset of the language is being used elsewhere. The complete lack of an ecosystem just reinforces that.

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

#90

Post by grandinj »

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.

Post reply on HN