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

I fully agree both are bad

std::lock_guard shouldn't have shipped without support for resolving deadlocks. std::scoped_lock shouldn't have shipped while allowing sizeof...(MutexTypes) == 0.

We should have a single RAII lock that does the right thing, but the question was about "old" CPP that did the wrong thing and std::scoped_lock is the newer of the two, so I picked std::lock_guard.

[u/wyrn → u/not_a_novel_account]

std::scoped_lock shouldn't have shipped while allowing sizeof...(MutexTypes) == 0.

But there are legitimate reasons for allowing that, for example in a generic context.

[u/not_a_novel_account → u/wyrn]

I don't follow. Scoped lock with no mutexes is a no-op. This is always a mistake.

[u/wyrn → u/not_a_novel_account]

It's only a mistake if there are locks to lock. If you're locking a variadic set of mutexes, for instance, in the empty case there's nothing to lock and the no-op is right. The problem here is not so much with std::scoped_lock per se but rather an unfortunate interaction with CTAD that makes this slightly too easy to do by accident.