Investigating the Performance Overhead of C++ Exceptions

Re:Investigating the Performance Overhead of C++ Exceptions by TeMPOraL on Tuesday February 11, 2020 @04:03PM (#22302814)

I don't recall NASA outright banning C++ exceptions - especially not organization-wide. Code running on space hardware has very specific risk profile, and AFAIK NASA dislikes exceptions there because they add risk to code (without a mechanism like Java's checked exceptions it's too easy to add a code path that can generate an unhandled exception, terminating the program).

[ Parent | on HN ]

Re:Investigating the Performance Overhead of C++ Exceptions by thedance on Tuesday February 11, 2020 @04:07PM (#22302854)

I'm sure it varies from one group to the other. This CppCon talk from 2014 says no exceptions are permitted in mars rover flight software.

https://github.com/CppCon/CppCon2014/blob/master/Presentatio...

[ Parent | on HN ]

Re:Investigating the Performance Overhead of C++ Exceptions by TeMPOraL on Tuesday February 11, 2020 @04:47PM (#22303265)

Yeah, but the slides don't give a reason why; the only hint is a prior slide mentioning the "historic arguments against using C++ in flight", namely "Exceptions: too much uncertainty, difficult to validate all possible control paths". And that has nothing to do with performance.

[ Parent | on HN ]

Re:Investigating the Performance Overhead of C++ Exceptions by klingonopera on Tuesday February 11, 2020 @04:56PM (#22303339)

ZeroMQ's author has written a wonderful article about how he should've picked C in place of C++ in a mission-critical setting, even despite personally preferring C++ himself.

http://250bpm.com/blog:4

[ Parent | on HN ]

Re:Investigating the Performance Overhead of C++ Exceptions by Fredej on Wednesday February 12, 2020 @04:38AM (#22307364)

This is an interesting post, definitely! However, as it was posted in 2012 I feel like some of his concerns have been addressed in newer versions of C++.

Instead of having a Constructor + init method you could have a static create function which returns an optional or a pair.

I have a hard time seeing in what case you would want to throw in a destructor though? Maybe I'm just writing a different kind of code :)

[ Parent | on HN ]

Re:Investigating the Performance Overhead of C++ Exceptions by TeMPOraL on Wednesday February 12, 2020 @04:51AM (#22307452)

> I have a hard time seeing in what case you would want to throw in a destructor though? Maybe I'm just writing a different kind of code :)

I can't imagine that case either - but what I can imagine is that your destructor calls a function that calls a function ... that calls a function you didn't realize can throw.

[ Parent | on HN ]

Re:Investigating the Performance Overhead of C++ Exceptions by sitkack on Tuesday February 11, 2020 @09:11PM (#22305123)

I really enjoy examples of analysis contravening ones opinions. We rationalize far too often.

[ Parent | on HN ]

Re:Investigating the Performance Overhead of C++ Exceptions by humanrebar on Tuesday February 11, 2020 @09:24PM (#22305173)

Well, mission critical software has to meet latency requirements, but it has to do so in a way that's provably bounded. In some ways, it's actually worth being a little slower if it's easier to prove you meet latency requirements.

Point being it's not entirely orthogonal to "performance".

[ Parent | on HN ]

Re:Investigating the Performance Overhead of C++ Exceptions by pjmlp on Wednesday February 12, 2020 @03:12AM (#22306891)

C++ had such mechanism before Java even, but it wasn't properly implemented, thus it got deprecated and eventually removed.

However value type exceptions might re-introduce it, just in a different form, with luck on C++23.

[ Parent | on HN ]

Re:Investigating the Performance Overhead of C++ Exceptions by gpderetta on Wednesday February 12, 2020 @05:01AM (#22307505)

C++ had runtime checked exceptions, which aside for the except/noexcept case, were pretty useless (and never implemented by MSVC).

I'm a huge fan of checked exception, given a type system powerful enough to parametrize over them (C++ should be more than capable), so I'm looking forward to the development. Stroustrup is not a fan though and he might kill the effort.

[ Parent | on HN ]

Re:Investigating the Performance Overhead of C++ Exceptions by pjmlp on Wednesday February 12, 2020 @10:02AM (#22309300)

I imagine that if value type exceptions get added, they will be exposed in the type system just like noexcept is.

[ Parent | on HN ]

Re:Investigating the Performance Overhead of C++ Exceptions by gpderetta on Wednesday February 12, 2020 @11:53AM (#22310405)

oh, yes. As far as I can tell, these static exceptions are basically syntactic sugar over an either<T, Except> return type, possibly with a custom ABI that stores the discriminant implicitly in a flag register (so on the call side you do not even need to load the discriminant and compare it and instead directly do a JMPcc ).

[ Parent | on HN ]