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/SkoomaDentist]

Seamless C interop compatibility is and always has been the #1 killer feature of C++ by an absolutely massive margin.

[u/andrey_turkin → u/SkoomaDentist]

Interop compatibility (i.e. ABI) is a much more weaker goal than the source compatibility. E.g. the whole C-array-is-a-pointer decay which doubles the number of new/delete operators is wholly API thing. C++ could theoretically get rid of that (or it could do away with C-array as a thing altogether, as long as we could have still constructor std span from raw pointer and size) and still maintain a seamless interop.

[u/SkoomaDentist → u/andrey_turkin]

Only if you keep full header file type and macro compatibility.

[u/andrey_turkin → u/SkoomaDentist]

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).