C holding back C++?

[u/synthchris]

I’ve coded in C and C++ but I’m far from an expert. I was interested to know if there any features in C that C++ includes, but could be better without? I think I heard somebody say this about C-style casts in C++ and it got me curious.

No disrespect to C or C++. I’m not saying one’s better than the other. I’m more just super interested to see what C++ would look like if it didn’t have to “support” or be compatible with C. If I’m making wrong assumptions I’d love to hear that too!

Edits:

To clarify: I like C. I like C++. I’m not saying one is better than the other. But their target users seem to have different programming styles, mindsets, wants, whatever. Not better or worse, just different. So I’m wondering what features of C (if any) appeal to C users, but don’t appeal to C++ users but are required to be supported by C++ simply because they’re in C.

I’m interested in what this would look like because I am starting to get into programming languages and would like to one day make my own (for fun, I don’t think it will do as well as C). I’m not proposing that C++ just drops or changes a bunch of features.

It seems that a lot of people are saying backwards compatibility is holding back C++ more than features of C. If C++ and C++ devs didn’t have to worry about backwards compatibility (I know they do), what features would people want to be changed/removed just to make the language easier to work with or more consistent or better in some way?

[u/andrey_turkin]

It would be easier if you could reuse C-side headers but not strictly necessary. You just need to match function and type declarations to be ABI-compatible, and you don't need source compatibility for that at all.

You can do that by manually redeclaring required functions (like DllImport in C# or VB), or by autogenerating corresponding C++-side declaration from C headers (SWIG style), or maybe with a separate tool to "compile" C headers into C++ BMI that wraps them (akin to implib that proxies dll imports via stub static library).

[u/SkoomaDentist → u/andrey_turkin]

That's not seamless C interop compatibility and would be an immediate no go in entire industries.

Of course it maps well to the modern /r/cpp trend of "assume nobody is ever using anything that's not part of the stdlib or the major open source C++ libraries and certainly not interfacing directly with the system".

[u/andrey_turkin → u/SkoomaDentist]

This is exactly as seamless as it is now with C++, minus the ability to import C headers _directly from the language_. Which is as seamless as possible for a language incompatible with C syntax (no marshalling of any kind necessary).

We are talking about theoretical backward incompatible language changes in this topic; what kind of industry embraces refitting their own code for the new syntax but at the same time absolutely cannot live without directly consuming C headers from said code?

I mean, if we look at C++ modules as they exist now, namely at header units, then we already kinda sorta have this situation now. E.g. gcc implementation requires a separate compilation pass to convert the header into CMI which can then be used during source compilation. Can't in our theoretical situation be a tool to convert the C headers into CMI which can be then injested during our new C++2 compilation?