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

101–110 of 516 posts

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

#101

Post by gpderetta »

mikepurvis wrote: post #87
chippiewill wrote: post #80

Earlier quoted context omitted.

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 f…

But you have exactly the same options in C++.

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

#102

Post by com2kid »

CyberRabbi wrote: post #73
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…

> Even if you avoid malloc,

Way too many people believe the difference between malloc/new+free/delete vs a GC is that one is deterministic and the other isn't.

(It doesn't help that textbooks still teach this!)

Both are subject to the whims of the system's memory and, if swap is enabled, IO systems.

And unless you understand your call graph very well, constructing an object that constructs other objects is not something you are likely to be capable of calculating the performance of in a non-GC language.

Same goes for destructors.

The actual difference is that in language without GC's typically have explicit syntax for dynamic memory allocation (though it can happen by surprise in C++ from time to time!), which means if you are writing latency sensitive code, you can just avoid dynamic allocation altogether.

But there is no reason why GC languages can't do the same! In fact, newer GC languages sometimes do, and nowadays C# give you more control over stack allocation, so careful C# coding can also avoid using dynamic memory.

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

#103

Post by DoctorDabadedoo »

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.

Ecosystem and performance.

There are other as performant languages out there that have a "small" footprint (C, Rust, Zig, etc.), but the combo with the libraries heavily used in robotics, mostly for image and mathematics computation, makes it hard to look away from it: C++ standard library, OpenCV, Eigen, Boost, PCL, ROS.

There may come a day when there is enough momentum and support to look elsewhere, but right now C++ is king in this domain. There is a lot of Python going on too, but usually not for the same type of things.

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

#104

Post by KerrAvon »

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.

For the sake of pedantry only: I don't think we called it RAII in 1993-1996, but the technique was in use in that period, though it wasn't standardized in any way. IIRC, Mac developers would have been widely exposed to it by Metrowerks PowerPlant during that time.

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

#105

Post by mhh__ »

cyber_kinetist wrote: post #46
worik wrote: post #31

Earlier quoted context omitted.

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

If you need any sort of numerical programming, C++ is basically unmatched. It's fast and efficient (have total control over memory and heap allocations), while able to create complex math abstractions thanks to its template system and operator overloading. For example, Eigen is the only library (not in C++, but in the entire programming space) that can optimize your math expressions at compile-time. You can also perf…

The D library "Mir GLAS" also does the eigen style optimizations, IIRC.

It's not unique to C++ but yes Eigen is by far and away the most mature option in that space. D templates are significantly better than C++ ones in basically every way, but the work is already done in C++ so I can't be too boastful

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

#106

Post by Koshkin »

physicsguy wrote: post #66
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.

That's not true. GCC, for instance, is a GNU compiler collection. (True, it does not include Rust, the last time I checked.) Other than that, there's always Java, Common Lisp, Haskell, and D. Plenty of choice there.

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

#107

Post by gpderetta »

WkndTriathlete wrote: post #65
jdlshore wrote: post #30

Earlier quoted context omitted.

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."

How is the implicit control flow in do notation different from exceptions?

If anything, the issue is between checked and unchecked exceptions.

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

#108

Post by HelloNurse »

masklinn wrote: post #52
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.

> 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. The problem is in that case you get into a probabilistic estimation, which is a nice way to say you roll the dice on your performances: what’s the ratio at which exceptions are too costly or sufficiently cheap? And how does that impact your level of service…

If the program fails too often or too unfairly, why should you blame how such failures are handled? The only reasonable "probabilistic estimation" is that something that happens 10% of the time is normal and it shouldn't be treated as an "exception", even if actually thrown exceptions were fast.

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

#109

Post by pjmlp »

mjw1007 wrote: post #79
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…

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.

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

#110

Post by usefulcat »

andi999 wrote: post #91
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…

How do you get memory without new nowadays?

They’re probably referring to preferring std::make_unique or std::make_shared to bare new/delete. Using either of the former makes the ownership semantics clear and avoids the need to remember to call delete at the appropriate time.
Post reply on HN