And C++{n+15} would have tons of new fun features so you can enjoy learning them in the next 15 years!

Yeah right, and after 10-15 years you'll be able to perform tasks without a problem that a 2-year experienced programmer can perform in a scripting language if (s)he wants to be expressive, or C if (s)he wants to achieve performance.

"Clever solutions give rise to artificial problems that can require even more cleverness to solve".

Not to mention the mad scientists sitting in ISO conference rooms constantly thinking "how can we top our previous clevernesses?". So good luck with the language being the same in 10-15 years.

These kinds of ridiculous statements poison the discussion and make it devolve into a complete mess. Stop that!

1) C is very difficult to use correctly even with the best guidelines and intentions. My best bet for avoiding memory errors is being super-careful (read: super-slow) AND using static analysis AND using Valgrind to check afterwards. The last two steps are mandatory.

Contrast this with C++, where just by using smart pointers, vector and array I can eliminate a whole bunch of typical C errors.

2) Scripting languages solve different problems than C++. The typical C++ tasks can't be performed by your programmer with 2 years of experience no more than they could by the same programmer if they had 40 years of experience.

Static analysis and Valgrind are wonderful.

This being said, I think I was six months into using 'C' when I mostly stopped having memory errors. Mainly, you construct the operations against memory objects based on building up series of constraints. This is less trouble than it sounds.

You learn to conform to the expectations of the language and libraries. And you use less of 'C' than there is to use. And when things get past a certain level of complexity, I tend towards making them state machines.

Should you have to do that? I have no idea. I do agree that based on most other people's 'C' code, it does appear to be painful for a great many people.

Do you have some example? I can't really picture the series of constraints that you mentioned...

RAII type things are part of it. The rest is simply making sure all the constraints are met. The fewer operational constraints, the better.

For text I/O parsing, just be semi formal about it at least. Check your indices, be careful of integer overflow and be judicious in the use of floating point. Use block I/O instead of the finer-grained things in stdio.h .

Have instrumentation built in that you can enable to capture test vectors ( if you have the resources ). Error counters can tell you a lot.

the mechanism of choice for managing complexity tends towards state machines and sometimes message passing.

That's a start.

Probably manual RAII. That seems to be where most stable C codebases end up, with a simple object model.

Are you speaking about libraries or the language itself?

Please detail what in C++ would take 10-15 years to be able to do, that would be possible in 2 years in other languages.