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.

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

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 :)

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

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

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