I can tell you how C++ will die. It will die because all C++ programmers will soon be dead for one simple reason: Our brains are incapable of knowing C++ well enough to write safe C++ code and knowing something else at the same time.
Knowing all the rules and exceptions to those rules in C++ will overwhelm the neocortex of C++ programmers and start to usurp older parts of the brain to the point where heart rate and body temperature get out of control and they/we all die an agonizing death.
As a C++ programmer I am struggling right now trying to leave this path to seemingly inevitable doom. But the insane complexity of C++ has this addictive allure of making me feel so incredibly competent and important, a bearer of secret knowledge that underpins the world's most important systems.
Basically, 99% of your work should use only about 10% of the feature set of C++ explicitly. The vast majority of the time, you shouldn't even write templates (just use the ones in the STL and project-specific ones that make sense).
But it's really nice that those other 90% of features are there when you need them.
I rarely use smart pointers that aren't implementation details (private class members)
Several of the techniques he promoted in 'Effective C++' (an old book now, I will concede) are and were, imho, somewhat unhealthy for the sake of being cautious. Another example are his recent talks on "universal references", introduced a whole fuzzy concepts to paper over one simple rule when rvalue references are combined with templates and type deduction.
His 'grunt on the ground' comment is typical of his humour, but he's really a bit of a navel-gazer... I don't think the difference between direct and copy initialization for type deduction of initializer lists is really going to make a difference to most C++ programmers work. The C++ committee generally does a very good job, and the fixes introduced by this change will most likely make a much greater positive impact.
I'm not looking forward to the first time I will have to work myself into a code base build around heavy 'auto' use.
And certainly - the case of auto x = T(); is not too bad. It's when the type is determined by template overload, or Koenig lookup, or template traits, that it becomes murky. It will take years for tool to catch up - now when I put my cursor on a variable, it will show me the type in the status bar. For the first few years this will always show 'auto' I'm afraid. In other languages, a collection is a collection (mostly) - in C++ it depends on whether you use a vector, set, hash or list what methods are available. That's quite a difference, from a programming comfort point of view.
If C++ is too complex for it to work, I'm just going to consider that a strike against C++ and move on. Chalk it up as another piece of evidence that C++ is wildly more complicated than Haskell.
I guess the more I think about it, that that's what scares me the most about 'auto' - instead of having the original author do the type deduction once (which is something he intended in the first place, hopefully), you now (as a maintainer) have to go chase it down, just to save the original author from typing out a hairy type.
Now I do realize the real use case for 'auto' - it's the cases where you don't actually know the type yet, because you're providing an extensible framework through template specialization. I have written quite a bit of such code myself. And yet, despite having suffered through all the 5-line typedefs that that sometimes required, I'd be willing to keep doing that to save myself from code by people who mistake 'auto' for a convenient way to save a few keystrokes (this is not meant as a jab at the parent, I'm just talking in general, in case anyone would interpret me wrong).
Eh... That can only be done by compiling the code in the background, while you're typing. Which is possible, of course, but it sets a very high barrier for tools. It will mean that only the top-3 of IDE's will provide this functionality, and even then, it will take them years to get it working well.
To become a member you need to pay for it, so most members are employees from compiler vendors.
Everyone else only gets access to what gets published as public information, hence the doubts due to not being present in those meetings.
The ANSI/ISO way seems like the opposite of what you'd want in a (open) programming language, doesn't it?
c++ is a big language with big grammar, as such offers a lot of different ways to say the same thing. each different construct is understood by a different set of code-readers, same way as in a complex human language. commenting c++ code is part of writing c++ due to this complexity, in my practice.
in a complex grammar, the order of words makes a difference and certain relation of grammatical constructs must be obeyed to remain comprehensive and understandable by most people.
communications using formal grammar makes it more understandable, versus slang. however both formal and informal convey the same information for the respective group of people.
in a programming language, pondering publicly about good and bad practices and their merit helps reading code, of course, with comments.
This is what I hate about Perl, so why do I like C++?
I'm quite willing to admit I'm irrational, but it feels like there's a big difference between the "there's more than one way to do things" style of both languages.
