I think the OP is trying to say that both C and C++ have international standards.
> Not exactly suitable for mission critical systems. The fact that they are used for that is more due to the fact that they can interface with hardware at a fairly low level and the amount of engineers with C (and nowadays, C++) knowledge.
And highly deterministic behaviors, crucial in real time systems. But I think Rust is trying to provide those guarantees too.
If Rust had a formal standard, and had the tool ecosystem, then I could see it being an interesting possibility for critical systems, certainly for the same places that Java + RTSJ would be appropriate. I won't be the first one to try and push a Rust-powered device through regulatory approval though.
Forgot about that, a very good point.
C++ is a subset of C, not the other way around.
> the fact that they can interface with hardware at a fairly low level
That's certainly one reason. Others include raw performance (think real-time safety-critical applications), no funny abstractions, tighter memory footprint, more flexibility, etc.
> and the amount of engineers with C (and nowadays, C++)
While I believe there are a number of C++ engineers out there, I'd wager that the number of competent C language engineers has dwindled over the years. Sure, everyone learns some C, but to know it well enough to write embedded real-time safety-critical systems is a whole different game. (not to mention the number of Java engineers has greatly outpaced even C++ engineers, thanks to University teaching Java, Android's dominance, and the lower barrier to entry).
> The 'formal' standard doesn't help you much when there's so much undefined behavior.
The formal standard defines what is undefined. Your safety-critical code shouldn't rely on some compiler-specific quirks or some magical code, but rather it should stay within the bounds of well-defined behavior.
I can't see how this statement could possibly be true.
> no funny abstractions
Really? Maybe I suck at C++, but I can't meaningfully reason about template-heavy code. Not about the run-time performance, nor resource consumption. STL and Boost are beyond funny if you ask me.
> The formal standard defines what is undefined. Your safety-critical code shouldn't rely on some compiler-specific quirks or some magical code, but rather it should stay within the bounds of well-defined behavior.
Agreed. But take a look at the specification and you'll be amazed on just how much stuff is left for the actual implementation to figure out.
Which is why the coding standard for a critical project will disallow the use of things that can lead to undefined behavior.
This is not true, the two languages have diverged: http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B
There's no C/C++. They are entirely different languages (even if C is supposed to be a subset).
Not exactly suitable for mission critical systems. The fact that they are used for that is more due to the fact that they can interface with hardware at a fairly low level and the amount of engineers with C (and nowadays, C++) knowledge.
The 'formal' standard doesn't help you much when there's so much undefined behavior.
Tool availability is a fair point.