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: 3, Informative) by N3Roaster on Tuesday August 19 2014, @05:08AM
For those curious, here are the main language changes [isocpp.org] and here are the main library changes. [isocpp.org]
Typica - Free software for coffee roasting professionals. [typica.us]
(Score: 3, Interesting) by nukkel on Tuesday August 19 2014, @05:28AM
C++, now with even more paradigms piled half-baked on top!
Is it procedural? Yes, but you really shouldn't.
Is it object-oriented? Only at compile time.
Is it a functional language? The preprocessor is.
What was missing? Oh, I know! Let's add an awkward closure syntax! Let's try to simulate weakly typed languages using the auto keyword!
(Score: 2, Informative) by Refugee from beyond on Tuesday August 19 2014, @07:00AM
What auto keyword has to do with weak typing? Auto variable doesn't change type in runtime.
Instantly better soylentnews: replace background on article and comment titles with #973131.
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @09:39AM
Well, some people obviously think just because they don't write down the type themselves, it isn't there.
BTW, I wonder if with the return type inference for lambdas with several returns, they allow for the same type inference as they allow for ?: since I think it would be frustrating if you'd do
and the compiler complains, while
compiles fine. Note that while in this specific case, the ?: is just as readable, in more complex situations it may not be.
(Score: 1) by tkd-physics on Wednesday August 20 2014, @03:10PM
Sarcasm fail.
Procedural? Yes, and you really should. Only the undereducated think OO is the only right way. Actually, only the undereducated think *any specific technique* is the only right way.
Object oriented only at compile time? Incorrect, OO is just about the only thing C++ can't do at compile time.
Functional? The preprocessor should be used as little as possible, but most compile time programming is functional. (Well, *all* of it with template metaprogramming, I'm not yet sure how the new constexpr stuff will work out.)
Awkward closure syntax? Weird, not awkward, a year from now nobody will notice. (The variable declaration syntax is awkward, but that was inherited from C, and everybody is used to that by now.) As I understand it, C++ lambda syntax is just about the only way they could make it work without breaking backwards compatibility. Or do you have a better way they could have done it?
(Score: 1) by c0lo on Tuesday August 19 2014, @05:28AM
Somehow, I don't feel sad.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by maxwell demon on Tuesday August 19 2014, @06:22AM
"C++0x forever" already ended when C++11 was finished (the version which was codenamed C++0x before).
The Tao of math: The numbers you can count are not the real numbers.
(Score: 3, Funny) by Tork on Tuesday August 19 2014, @05:28AM
Okay I kid, I know they're talking about documentation. But I did run across a class in the scripting API for an application my company uses where there are two members, one is spelled right, the other is spelled the way you'd spell it if a little squiggly line didn't appear under it.
MyClass.Aperature
MyClass.Aperture
I really don't know whether to applaud them for maintaining compatibility or for cementing both variables in. Heh.
🏳️🌈 Proud Ally 🏳️🌈
(Score: 1) by rfree on Tuesday August 19 2014, @07:37AM
This is cool news :)
C++14 changes are rather fixes, not a revolution like C++11, but it's nice they are here to be implemented.
The glorious C++ master race will be even better then all the C, Java, PHP peasants, wooo.
(Score: 3, Funny) by aristarchus on Tuesday August 19 2014, @09:14AM
Isn't it the C-14 isotope that allows for carbon dating of really old stuff? Oh, C++? Wait, isn't that like C, and isn't that just glorified Pascal? Wait again, it is really old!
(Score: 3, Insightful) by kaszz on Tuesday August 19 2014, @09:35AM
So did Apple objective and Microsoft sharp get their peeve and others their pile-upon-the-old stuff included? Must be a dream to use.. (while your MBA boss wonders why things break)
Seems they did C right and then it got serious warts but warts was a feature.. a wart++ feat! ;)
Languages need to be stringent and efficient. Refactoring the design is sometimes a necessary evil.
(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).
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @11:42AM
C++ never sat right with me. As someone who literally grew up writing assembler, I have difficulty seeing how the C++ way of doing things is much better than C. It seems like all of C's pitfalls are hidden behind a Wizard of Oz curtain until you abstract your way into a brick wall and have to face them. I don't like a language where the subroutines you tend to write don't work very well as boxes in a flowchart, either.
Here's a fun question: what makes C++ any better than some sort of compiled BASIC? What does C++ do that C doesn't do, besides give you the ability to dig yourself into a hole much faster?
GET OFF MY LAWN!
(Score: 3) by HiThere on Tuesday August 19 2014, @01:01PM
Well, the ability to have variables contained within object instances is nicer than needing to stick them on the heap yourself. I really miss that whenever I use C. OTOH, C++ comes with some much stuff done as templates that I generally use something else. I understand that doing it as templates means that it can be done at compile time rather than at run time, and for some purposes that's optimal, but sheesh! I just don't think that way. Scheme is easier to wrap my mind around.
The language I actually prefer is D (Digital Mars D) when I'm not using Python or Ruby. D has all the nice features I like from C and doesn't yet require that you pay much attention to templates. Unfortunately, there are signs that its developing into the same mess. Apparently once you allow templates into a language, the developers get all caught up in it, and think it's so nice that everyone must want to use it.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @04:04PM
Actually I don't understand why so many people have an aversion to templates. I mean, the template syntax in C++ is ugly, yes, but that's just a cosmetic problem. And from the little I've seen from D, its template syntax seems not to be bad.
Especially if you only use templates, rather than writing them, most of the time the only thing you notice is those angle brackets in the type name. For functions, you normally don't even have that; you just write min(a,b) and don't care whether min is a template or not. Except that as template, it automagically works with your own classes as long as they define a less-than operator.
Yes, you can also do mighty complicated stuff with templates. But nobody forces you to do it. Just like nobody forces you to do mighty complicated stuff with functions.
(Score: 2) by PizzaRollPlinkett on Tuesday August 19 2014, @02:17PM
A big win: You don't have to start from scratch writing linked list and dictionary code for your structs. I used C++ on a project that would have used C otherwise, just to get the standard containers - after a decade and a half of using Java, I wasn't about to start writing data structures from scratch. C++ saves a ton of programmer time with containers, iterators, etc.
(E-mail me if you want a pizza roll!)
(Score: 2) by forsythe on Tuesday August 19 2014, @04:09PM
The obligatory ``interview'' should be posted about now. [cat-v.org] As someone who has to read code written by others, C++ (compared to C) offers a myriad of ways to obfuscate errors behind layers and layers of design patterns, while offering nothing really more significant than pre-written linked lists.
(Score: 1) by hendrikboom on Wednesday August 20 2014, @06:30PM
So, was that a real interview?