←back to thread

93 points endorphine | 1 comments | | HN request time: 0.254s | source
Show context
ajross ◴[] No.43537017[source]
This headline is badly misunderstanding things. C/C++ date from an era where "correctness" in the sense the author means wasn't a feasible feature. There weren't enough cycles at build time to do all the checking we demand from modern environments (e.g. building medium-scale Rust apps on a Sparcstation would be literally *weeks* of build time).

And more: the problem faced by the ANSI committee wasn't something where they were tempted to "cheat" by defining undefined behavior at all. It's that there was live C code in the world that did this stuff, for real and valid reasons. And they knew if they published a language that wasn't compatible no one would use it. But there were also variant platforms and toolchains that didn't do things the same way. So instead of trying to enumerate them all individually (which probably wasn't possible anyway), they identified the areas where they knew they could define firm semantics and allowed the stuff outside that boundary to be "undefined", so existing environments could continue to implement them compatibly.

Is that a good idea for a new language? No. But ANSI wasn't writing a new language. They were adding features to the language in which Unix was already written.

replies(5): >>43537270 #>>43537327 #>>43537466 #>>43537560 #>>43537849 #
1. VWWHFSfQ ◴[] No.43537327[source]
I don't think the headline is misunderstanding anything.

These things are both true:

> C and C++ Prioritize Performance over Correctness

> C/C++ date from an era where "correctness" in the sense the author means wasn't a feasible feature.

So correctness wasn't feasible, and therefore wasn't a priority. The machines were limited, and so performance was the priority.