Herb Sutter reports that the ballot closed on Friday.
From the announcement:
We will perform some final editorial tweaks, on the order of fixing a few spelling typos and accidentally dropped words, and then transmit the document to ISO for publication this year as the brand new International Standard ISO/IEC 14882:2014(E) Programming Language C++, a.k.a. C++14."
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @03:56PM
There are situations where the copy constructor can not be elided. Also note that you'll have to make your test with a C++89/C++03 compiler, since a C++11 compiler will automatically call the move constructor if available and applicable, without you needing to explicitly request it. Also note that a move constructor is only useful for classes which hold resources (like containers which manage collections of objects on the heap).
The move constructor basically makes a shallow copy, followed by changing the original so it can be destructed/reassigned without deallocating the resource (which now belongs to the newly constructed object).
That the move constructor was needed can also be seen from the auto_ptr fiasco. Without move construction, the standard committee, who are, after all, the ones who know C++ best, did three iterations of auto_ptr, and each of the three turned out to be defective, and finally they found out that you simply could not write a non-defective auto_ptr in the old language. In C++11, a beginner could design a functional auto_ptr replacement (not that he would need to, since the standard provides the new unique_ptr which does that).
And the nice thing about the move constructor is: In 99% of all cases you don't even need to think about it, provided you've used best practices already from C++98. The compiler will do just the right thing for you. And if you completely ignore it, the worst thing that happens is that your code will have the same performance as it would have in C++98.
Unless, of course, you're trying to implement something with auto_ptr like semantics. Then the worst thing that can (and will) happen if you ignore move construction is that you'll fail to provide a correct solution, because without move construction and move assignment, there simply isn't one. But then, your cdoe would have been just as broken when compiled by C++98. You just lost the justification that there's no way to do it correctly, because now there is.
You have a very good point about syntax. However, while C++ certainly produced its own problems (you've already mentioned the ugly template syntax), part of the problems is already in the C language, which simply wasn't designed for the type of extensions C++ did. Indeed, C stopped being context free when introducing typedefs; in the context of C that was not a big problem because it was always clear whether something is a type or not, but in C++ templates that is no longer the case, which leads to the typename complexities). Indeed, the biggest mistake of C++ in my opinion is C compatibility. Had they made a clean break, like Java, C# or D, this would have enabled a much improved syntax. The only worse thing is that in C++11, they disallow narrowing conversions, but only in new initializer syntax. While the goal is laudable (decrease the chance of errors through a misfeature inherited from C), the implementation is despicable (by only disallowing those conversions in some contexts, the complexity of the language is unnecessarily increased; not adding those restrictions would have been preferable to partially applying them; applying them everywhere would have been even better, but would have broken old code relying on them).