News for hackers. Stuff that matters.
Re:The problem with C by grive on Thursday September 03, 2020 @06:17AM (#24362546)
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.

Re:The problem with C by flohofwoe on Thursday September 03, 2020 @06:41AM (#24362654)
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.

Re:The problem with C by scatters on Thursday September 03, 2020 @10:53AM (#24364604)
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.
Re:The problem with C by flohofwoe on Thursday September 03, 2020 @11:09AM (#24364771)
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).
Re:The problem with C by i-am-curious on Friday September 04, 2020 @03:11AM (#24372501)
Doesn't LTO interfere with debugging massively?
Re:The problem with C by josefx on Thursday September 03, 2020 @11:01AM (#24364683)
> 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.

Re:The problem with C by qalmakka on Thursday September 03, 2020 @11:38AM (#24365067)
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.
Re:The problem with C by flohofwoe on Thursday September 03, 2020 @01:06PM (#24366143)
Microsoft dropping their own C compiler and using Clang as the standard C compiler in Visual Studio would be great TBH.
Re:The problem with C by colejohnson66 on Thursday September 03, 2020 @06:46PM (#24369710)
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.
Re:The problem with C by qalmakka on Friday September 11, 2020 @05:42AM (#24440808)
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.