Comment by etyp | Hacker News Reader

Comment by etyp | Hacker News Reader

I don't think the C++ standard can be held up like that. Many compilers simply ignore it (or ignored it, they're getting better about these things). It's not because there's an omission, it's because writing a compiler that conforms to a thousand page document of rules is hard. And tedious. Some will fall through, there is no "one true C++" that follows the standard perfectly, most fall short. The ambiguity is still there, many times you can read the standard and know what the compiler will do, but many times you can't. Even if the standard is unambiguous.

So with Rust, the implementation is the specification. The author mentioned gccrs - hasn't that already had some positive standardization benefits without a true standard? I'm not super knowledgable about the status there, though.

I feel like more standardization is certainly worthwhile, but writing a specification is an entirely different beast. I see that as years of painstaking work just to keep everything mostly the same and harder to iterate. Seems like a hard sell even if it would be great for systems programmers ;)

> For developing external code analysis tools such as Coverity

You can do that by just using intercepting `rustc` and using the static analysis tool's common IR(s), right? I'm nitpicking here, though.

The major C++ compilers are perfectly conformant with the standard. Where they can lag is after standards come out. Modules have been a challenge, but other language features get implemented within a few years. At the time of writing, all the major compilers conform with C++ 17 and aside from modules, conform with C++ 20. There absolutely is "one true C++" as set by the standard, and compiler writers have a roadmap for how to conform to it.

"The implementation is the specification" is frankly a sophomoric position. It works fine for small projects and projects of limited complexity, but Rust is neither of these.

Looking over https://en.cppreference.com/w/cpp/compiler_support, it seems there is good conformance on C++11 and C++14 but there are gaps on C++17+ among gcc, msvc, and clang.

The gaps are on the standard library side: clang libc++ has fallen behind a bit on conformance, but you can use libstdc++ on clang as well (and it is the default for example on Linux). MSVC lags on C conformance, which is known not to be primary concern for MS (but still miles better than what it used to be).

In any cases these tables only help up to a point, even green cells often hide bugs and conformance divergences.

Still for most straightforward code compliance across compilers is very good and significantly better than the dark ages of two decades ago.

Completely agree. I'm only calling it out because of the claim "perfectly conformant with the standard".

The compiler is conformant. The STL is not necessarily.

Reply on news.ycombinator.com