SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 7 submissions in the queue.
SoylentNews
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Love is in the offing. Be affectionate to one who adores you.
(Score: 4, Insightful) by PizzaRollPlinkett on Tuesday August 19 2014, @11:38AM
I'm so old I can remember when C++ was a nice little OO language with a lot of promise, poised to replace C as a systems programming and general purpose language. Sure, it had its quirks, but all languages do. The word "virtual" was overloaded too much, and the allergic reaction to using new keywords caused bizarro syntax like using "= 0" for abstract methods. Such syntactic oddities made the language much harder to read than necessary, since you had to mentally de-obfuscate C++ code as you read it. But multiple inheritance was not a requirement, and you could ignore it. So the potential was there.
Then the bottom fell out. C++ got bizarre and weird during the standards process, with such misfeatures as the template syntax which was difficult to read. The language became inscrutable, and hard to compile. The language became inbred, with C++ experts working on adding features to the language that only C++ gurus could understand, locking out the very programmers who were ready to make C++ the next Language Of Choice but who were turned away by C++'s inscrutable syntax and mind-bending complexity.
The C++ world retreated into a hard shell, being ignored by programmers who moved on to more sane languages. Finally, the C++ 11 standard came along, reminding programmers both that C++ had once been relevant, and also why they ignored it in the first place. The bizarro lambda syntax was so strange that only inbred C++ programmers could have come up with it. The hyper-allergy to adding new keywords forced C++ gurus to basically create gibberish out of square brackets.
Everything you need to know about C++'s demise is in the "move" constructor. I'm still not completely sure what it does, but someone did a test and the g++ compiler already optimized object moves. If compilers are already so smart that they can do this, why does the language need to add a complex and inscrutable feature that's hard to even explain?
I can remember being excited about C++ at one time, around 1993 or so. Since then I've only done one project in it.
(E-mail me if you want a pizza roll!)
(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).