C compatibility was the very reason for which C++ is bigger, more complicated and less safe than a similar language not compatible with C could be.

Objective C and D both have excellent C compatibility. C# has very good one. I think all 3 languages are easier to use.

They all may have excellent C compatibility, but this is not the point. The point is that without C compatibility C++ could be smaller and simpler, and yet still meeting the same goals and covering the same use cases. Objective C has Smalltalkish object system glued to C base. Fundamental C++ techniques like RAII not possible there. D has GC. C# runs in a VM. I would not call a language with any of those features very similar to C++.

OTOH if not for C compatibility we would not have this discussion, since we would most likely never heard of C++.

Really? C++ accidentally has a Turing complete templating layer. I suppose one could point to Common Lisp but if you think that is simple....

Well, Common Lisp is simple. Except maybe the Metaobject Protocol (which ultimately didn't make it into standard, but it sort of still is). And except eval-when. Eval-when is magic.

I never said that this language would be simple. Just simpler than C++ we know.

I'm having some difficulty imagining that C is safer than C++.

Well, it is. Every f*up you can have in C, you can also have in C++.

Only if you write unidiomatic (Read crap) C++.

In modern C++ it is very much possible to write fast and safe code, but the tradeoff is now put into the amount of stuff the developer needs to know to be productive (Which in my experience isn't as bad as people like to go on about on here/reddit, even if it still pretty shoddy)

> Only if you write unidiomatic (Read crap) C++.

Thats a bit unfair. A recent headache for my C++ project was mixing audio buffers. The buffers are cached to avoid repeated reads, the channel count differs, the sample rate can differ, the output rate can differ, and mixing has gain limiters applied etc. Lots of buffers, lots of copying, lots of boundary cases (eg. sample #1 doesnt start until t=100ms, sample #2 ends before sample #1, etc).

I struggled for days getting all the buffer copying right (raw pointers to many interrim buffers). You may think that my problems were due to using "crap c++ in unidiomatic way". However, I challenge you to find a better, and as efficient method to accomplish the same goal. The end MixAudio() function looks like plain old C code from the early 80's, but how else can you tackle this problem in a modern way?

> I struggled for days getting all the buffer copying right (raw pointers to many interrim buffers).

It seems like you struggled with math (indexing logic) rather than C++.

> how else can you tackle this problem in a modern way?

You could try to write an iterator that takes into account sample rate, channel count, etc. That way the logic for handling buffer formats and iteration over samples is encapsulated into a single reusable component.

I'm not entirely sure - only just learning audio programming atm, but the way to approach would be to encapsulate then use encapsulation and ranges/iterators.

Efficiency should be roughly the same, especially given that you can optimise loops (and other code) with just as much access.

Sure, but with C++ there's fewer reasons to do so.

Stroustrup likes to say it's harder to shoot yourself in the foot with C++, but when you do it tends to blow off the whole leg.

Jokes aside, I think D is it. And with the `-betterC` switch it even has replicated that C subset, but without actual legacy baggage.