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

421–430 of 516 posts

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

#421

Post by masklinn »

Inityx wrote: post #313
masklinn wrote: post #57

Earlier quoted context omitted.

> Not sure if the Rust implementation has a different design to make it perform better though. Prolly not, I expect the issue comes from the increase in branches since a value-based error reporting has to branch on every function return. Even if the branch is predictible, it’s not free. And fib() would be a worst-case scenario as it does very little per-call, the constant per-call overhead would be rather major.

It's also worth noting that Rust does also have stack-unwinding error propagation, in the form of `panic`/`catch_unwind`, which can be used as a less-ergonomic optimization in situations like this. Result types like this also don't color the function, since you can just explicitly panic, which would be inlined at the call site and show similar performance to C++ exceptions.

This is very much non-idiomatic. Panics are not intended as “application” error reporting, but rather as “programming” error.

The intended use-case of catch_unwind is to protect the wider program e.g. avoid breaking a threadpool worker or a scheduler on panic, or transmit the information cross threads or to collation tools like sentry.

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

#422

Post by ModernMech »

ncmncm wrote: post #402
ModernMech wrote: post #380

Earlier quoted context omitted.

Fred Brooks put it this way: "I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas." IMO C++ does not have conceptual integrity.

A language that has stopped responding to the evolving needs of its user community is a dead language. C++ is not a dead language. Your complaint is that it is not dead.

No, a language can stay current by evolving to fit its purpose. A good example of this is Matlab. Matlab is older than C++ and is still heavily used today, enough that it's one of the few remaining programming languages to support an actual business.

Matlab is not the same language it was in the 70s. But the core language is still largely about manipulating arrays and it does it well. It has evolved by adding functionality through toolboxes and creating new, innovative developer tooling. But it hasn't jumped on every PL bandwagon that has driven by over the last 50 years.

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

#424

Post by jcelerier »

JAlexoid wrote: post #330
jcelerier wrote: post #292

Earlier quoted context omitted.

So interesting, to me a language being opinionated is the main reason to put it on the do-not-use bin. I strongly believe that the best way to develop is through embedded domain-specific languages adapted to individual problems, and opinionated languages are always way too limiting regarding that.

Your statement contradicts itself - you're against optionanted languages, but insert an opinionated language(DSL) into an unopinionated language.

When it's an embedded dsl you always have the escape hatch of the entire host language - and it is not shocking to use it: being in an eDSL does not mean that you have to agree to it religiously, it's always a case-by-case engineering tradeoff.

Whereas when in an opinionated language and you cannot do what you want... Ugly hacks such as people using bash scripts, mustache templates, etc ... to preprocess their code to get what they want quickly happen.

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

#425

Post by ModernMech »

ncmncm wrote: post #401
jerf wrote: post #206

Earlier quoted context omitted.

A lot of that is not what I mean by "churn". What I mean by "churn" is changes in best practice . Python has been adding a lot of features, but with the possible exception of static typing support, most of them haven't made many changes to what constitutes best practices . They might make "nicer ways to write that code" but the old styles haven't been deemed wrong . async is also not exactly what I mean; this allows…

C++ gets new features that provide a better way to solve common coding problems. This is not accidental, and not a problem: the new features were added because they offer that better way. Failing to use the new feature is just failing to write code the best way that is available right now. In 2013 you had no choice but to do it the old way; but you don't have to anymore, because the language and std library have caug…

> This is not accidental, and not a problem

You're right it's not accidental, but the problem is that when you continually add new features you end up creating a confusing mess. Yes, the new features may respond to some need in the community, but by adding it you've also:

- Introduced possibly unforeseen issues because features are never added in isolation; they interact with one another, and the more features you have the harder it is to test them all.

- Created confusion because now all the old information on the internet is out of date

- Everyone needs to update their tooling to support the new features.

- Make it harder for new people to start learning the language

> Failing to use the new feature is just failing to write code the best way that is available right now. In 2013 you had no choice but to do it the old way; but you don't have to anymore, because the language and std library have caught up with you.

This is a nice idea but it doesn't reflect reality. If the C++ user survey [0] is to be believed, a full 67% of users were restricted from using the latest C++ at the time (either fully or certain features).

> Being responsive to the needs of its community of programmers is job one for a language committee.

This is true but it also must be balanced against mission scope creep and design considerations. Being everything to everyone is not design.

[0] https://isocpp.org/files/papers/CppDevSurvey-2018-02-summary...

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

#426

Post by cesaref »

nemothekid wrote: post #305
cesaref wrote: post #231

Earlier quoted context omitted.

I've worked in low latency trading, and with large distributed back testing setups with hundreds of high core count machines, and not once felt the need to disable exceptions, or for that matter, felt the impact of them happening. A fair bit of noexcept stuff was useful to improve runtime performance, but that was about it. I would suggest you need to address that 1% of failing tasks and determine what the issue is,…

I'm not sure I understand the appeal of C++ exceptions. For years I've been told that Rust and Go's lack of advanced exception support is a crutch; and that error returns or sum types were unimaginative. Now, in this thread, exceptions are supposed to be used rarely. I don't see the difference between an exception and Rust/Go's `panic`. If the error is rare enough, then chances are you cannot gracefully recover. If t…

Exceptions have always supposed to be used rarely - that's the point! The most obvious example is 'new' failing and returning std::bad_alloc. Given that new is implicit all over the place (pushing to a vector for example) the code would get very cluttered if you had to cope with this everywhere, so the pragmatic decision was taken to use exception handling to give apps that cared the chance to deal with them, and those that don't a sensible error message by default when the exception escapes main.

It's interesting that the lack of enforced exception handling was seen as a strength when exceptions were added to the language, compared to now when the lack of enforced exception handling is sometimes seen as a weakness. Programming language design and expectations are a moving target, so it'll be interesting to see how these things develop over time.

And yes, Rust and Go take a different approach. Is there right and wrong? No, i'd say just different approaches which will play to the strengths of some problem domains and coding styles.

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

#427

Post by cesaref »

CyberRabbi wrote: post #310
cesaref wrote: post #231

Earlier quoted context omitted.

I've worked in low latency trading, and with large distributed back testing setups with hundreds of high core count machines, and not once felt the need to disable exceptions, or for that matter, felt the impact of them happening. A fair bit of noexcept stuff was useful to improve runtime performance, but that was about it. I would suggest you need to address that 1% of failing tasks and determine what the issue is,…

Low latency is not the issue per se. It’s more like being able to guarantee a worst case upper bound runtime. Maybe your system can tolerate indeterminate but rare worst case run times but many useful systems cannot. E.g. flight control systems but also ideally any interactive system.

Well i'm now working in a hard realtime domain (audio, noone dies when it goes wrong, but it's still hard realtime) and i've still got exceptions turned on. But no exceptions are thrown during runtime, they're there for exceptions. Yes, there's overhead in places, but we noexcept some code paths to reduce that overhead in some very hot code paths.

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

#428

Post by physicsguy »

Koshkin wrote: post #106
physicsguy wrote: post #66

Earlier quoted context omitted.

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.

They're hardly comparable languages are they? If I want to write some embedded software or work on a POWER9/10 machine at work, I'm basically limited to C or C++.

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

#429

Post by ncmncm »

ModernMech wrote: post #422
ncmncm wrote: post #402

Earlier quoted context omitted.

A language that has stopped responding to the evolving needs of its user community is a dead language. C++ is not a dead language. Your complaint is that it is not dead.

No, a language can stay current by evolving to fit its purpose. A good example of this is Matlab. Matlab is older than C++ and is still heavily used today, enough that it's one of the few remaining programming languages to support an actual business. Matlab is not the same language it was in the 70s. But the core language is still largely about manipulating arrays and it does it well. It has evolved by adding functio…

Matlab usage has been in decline for many years.

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

#430

Post by ncmncm »

ModernMech wrote: post #425
ncmncm wrote: post #401

Earlier quoted context omitted.

C++ gets new features that provide a better way to solve common coding problems. This is not accidental, and not a problem: the new features were added because they offer that better way. Failing to use the new feature is just failing to write code the best way that is available right now. In 2013 you had no choice but to do it the old way; but you don't have to anymore, because the language and std library have caug…

> This is not accidental, and not a problem You're right it's not accidental, but the problem is that when you continually add new features you end up creating a confusing mess. Yes, the new features may respond to some need in the community, but by adding it you've also: - Introduced possibly unforeseen issues because features are never added in isolation; they interact with one another, and the more features you ha…

You are very confused.

People not using the latest Standard are waiting for support within their particular environment, not because they want to stay with a less performant version of the language.

Post reply on HN