Hacker News Reader

Comment by grive | Hacker News Reader

It's weird to conflate C as a language and its ABI, as the glue between other languages. The glue in question is the ABI, period. Rust does not interface with C, it interfaces with a C library (dynamic or static) that is in a standardized format.

C++ attempts something messy, which is to take C source and generate objects conforming to this ABI. In doing so, the only sane thing to do is to respect the C spec to transform C source in a binary blob that others can understand.

C++ should stop attempting to parse C. Just use a C compiler, create a binary blob and interface with it from the C++ compiler. Attempts to make both language compatible on some common subset makes them both worse off.

View on HN

IMHO C++ should continue to be able to parse C declarations (e.g. include a C header which only has declarations in it - in fact, all languages with C interoperability should have this feature), but otherwise I agree, C++ doesn't really need to be able to compile C code because (usually) it's trivial to setup a mixed project where C source files are compiled with a C compiler, and C++ source files are compiled with a C++ compiler.

This requires that the Microsoft C compiler is updated to the latest C standard though. Until recently their recommendation was to compile C code with the MSVC C++ compiler.

A C header can contain function definitions, though - either using the inline keyword (since C99) or as macros. Moving all functionality behind a function call barrier may not give satisfactory performance.

Yeah, adding the inline keyword to C wasn't such a great idea in hindsight because it muddled the separation of interface and implementation (LTO is the better solution IMHO). A possible workaround would be that such a "declaration parser" would ignore the function implementation block (but inline code would make the library unusable from C++ anyway). As for macros: they would simply be resolved by the declaration parser, and either the result is parsable as declarations or not (which would then be an error).

Doesn't LTO interfere with debugging massively?

> e.g. include a C header which only has declarations in it

That seems like an awful amount of work just to prevent C++ programmers from using any existing C library.

Clang has been able to parse MSVC headers and link with its libraries for years now. It also supports the same interface that CL provides using clang-cl, so it's not that that necessary for Microsoft to actually update the entire compiler; they just need a few library changes in order to fully implement C99/C11.

Microsoft dropping their own C compiler and using Clang as the standard C compiler in Visual Studio would be great TBH.

They probably haven’t yet because of backwards compatibility. I’m certain there’s plenty of companies that take advantage of the quirks unique to MSVC++ and would be quite upset if it was just replaced with GCC or LLVM.

This, exactly. MSVC is full of extensions so heinous and horrible to make you scream when you sleep at night. They probably pledged to support those until the end of time, so I guess they would have to keep CL around forever.

Also, if you manage to overcome how horrible their CLI tools are, Microsoft's CL is a nice C++ compiler. Their STL support is great nowadays and lots of things just work; I even had seen times where they were _stricter_ about standards than Clang/GCC, which honestly shocked me.

Reply on news.ycombinator.com