[rezonant]

As with all of the languages you mention, consuming C from the other language is trivial. And since C++ is a superset of C that is certainly true there. Consuming the other language from C is difficult without a C compatible runtime API to help bridge the gap.

Of course the issue for C++, unlike the other examples here, is that it does not have a runtime layer that can be used to bridge the gap. So we either write a wrapper in C++ using extern C, or use a tool to do it.

It seems there was a GSOC effort for SWIG to generate C wrappers for C++ libs but it might not have made it all the way? I don't see C as a target language on SWIG's site.

Still, a bespoke, high level design for the C wrapper is always going to be less painful for the consumer.

[kaashif]

> And since C++ is a superset of C that is certainly true there.

C++ is not a superset of C. C99 has and C++ (at the time of writing) doesn't have: restricted pointers, designated initializers, variable length arrays, and probably more. These are language features that are actually used.

This doesn't change any of your core points.

[ftaghn]

> variable length arrays

It was such a terrible feature it was made optional in the C11 standard (you can be a conforming C11 compiler and not allow this feature) and will never, ever be implemented in a Microsoft compiler (while C is not a priority for MS, do note that they updated to C11 and C17).

You can hear their reasoning there :

https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-...

The linux kernel used to make use of the feature and removed every instance of it from the code base :

https://www.phoronix.com/news/Linux-Kills-The-VLA

> Particularly over the past several cycles there has been code eliminating the kernel's usage of VLAs and that has continued so far for this Linux 4.20~5.0 cycle. There had been more than 200 spots in the kernel relying upon VLAs but now as of the latest Linux Git code it should be basically over.

While I do agree that it is wrong to consider C++ a superset of C, it is time to forget about C99's biggest mistake and treat it as if it didn't happen.

[kaashif]

Agreed completely on all counts.

Never ever use VLAs.

My point is really just semantic, the overall argument I was responding to is intact.

[patrick451]

C++ has had designated initializers since c++20.

[kaashif]

Point taken, I was inaccurate. Out of order designated initializers still don't work in C++20, right? Which still means C++ isn't a superset of C.

[turndown]

Any look into this will show that C's designated initializers are significantly more flexible/better in every way.

[SubjectToChange]

It’s amusing to me that whenever C has a feature that C++ doesn’t, C programmers hammer on the usefulness and power of said feature, but on the converse those same C programmers hammer on the divine simplicity of C.

C++ has constructors, it doesn’t really need designated initializers in the first place. They were added primarily for C compatibility.

[zabzonk]

> Of course the issue for C++, unlike the other examples here, is that it does not have a runtime layer that can be used to bridge the gap

neither, per standards, does c

[rezonant]

Yes, but C is simple (and standard) enough that higher level runtimes have more or less universally managed to construct decent FFI mechanisms to access it.

C++ FFI would be kind of feasible if mangling were standardized (for instance) :-/

[SubjectToChange]

Standardizing name mangling would only be a baby step towards C++ ABI compatibility, sadly.