Re: Direction number one
I recently started doing some serious C++ work using Qt and I was pleasantly surprised just how much the language had evolved
The problem isn't C++ the language, which can indeed be very good if used judiciously by someone dedicated to the craft. (That sort of programmer is rare, true; but then the other sort will write crap in any language.)
The problem is the vast corpus of existing C++ code. I've seen tens of thousands of lines of C++, in more than a hundred projects, from perhaps a few dozen organizations / teams / individuals. Nearly all of it is horrible: inconsistent, nearly unreadable, ill-conceived, and dangerous. Most of it fails to use even constructs from the '98 standard when it should, much less newer features. I don't know how many classes I've seen that muck up things like basic memory handling, for example by using default copy constructors and assignment operators when the class contains dynamically-allocated storage.
Most of the decent C++ source I've seen is in textbooks - Stroustrop's own, Meyers' Effective C++, etc. But those models aren't adopted by most C++ programmers, it seems. C++ provides far too much freedom to an undisciplined development team, and most of them are undisciplined.
So working with an existing C++ code base - and greenfield projects are relatively uncommon - generally means a three-way Hobson's choice: a huge refactoring effort, copying the broken style of the old code, or writing new code in a better but inconsistent style (and increasing surprise for later maintainers).
There's no way for C++17 to fix that, though. Stroustrop's plans for it are reasonable. But as with previous updates, they'll help the good programmers much more than the bad ones, and they can't fix existing code.
Biting the hand that feeds IT
