Slashdot Mirror
New C++ Features Voted In By C++17 Standards Committee (reddit.com)
New submitter lefticus writes: The upcoming C++17 standard has reached Committee Draft stage, having been voted on in the standards committee meeting in Oulu, Finland this Saturday. This makes C++17 now feature complete, with many new interesting features such as if initializers and structured bindings having been voted in at this meeting.
An [audio] interview with the C++ committee chair, Herb Sutter, about the status of C++17 has also been posted.
An [audio] interview with the C++ committee chair, Herb Sutter, about the status of C++17 has also been posted.
Unfortunately the most important features weren't added. Concepts, modules, reflection and concurrency ... those would actually fixed almost all the things, where c++ is lacking now. Hope those will get into the next standard at least.
No because you can't put a declaration inside the if statement right now. You could use the comma operator to give an already declared variable a value before the boolean expression, but the variable would have scope outside of the if statement.
Yes, you can. The example I showed above works right now, and always have. The problem is that it declarations evaluate to their values, so you can only do it if the value is something that has a useful boolean conversion (like not-null of pointers). The standard would expand the same to more types of expressions. But I can't see why this wouldn't already work:
if (MyClass *p = getMyClass, p && p->ofTheRightType())
p->doTheRightThing()
Wait, I think I figured it out. The comma operator doesn't work after declarations. In a declaration a comma signifies a declaration of another variable of the same type.
You need to divide C++ into two sections: Stuff that's useful for applications, and stuff that's mostly relevant to library writers. A lot of the really hairy stuff is mostly for the library writers. Moreover, a lot of the complexity of C++ (and corresponding slowness of its compilers) comes from compatibility with C and with older versions of itself. If you strip away all that, the core language that most people deal with isn't quite as daunting.
That being said, nobody is claiming that C++ isn't a difficult language to master. Scott Myers has made a career of pointing people away from it's darkest corners, after all.
But really, C++ programming took a quantum leap forward with C++11, and C++14 just filed away some of the rough edges. It's hard to explain to non-C++ programmers what a transformation it was. I'm not expecting nearly as much with C++ 17, but I look forward to seeing if any of the proposed features will be useful in my day-to-day work.
Irony: Agile development has too much intertia to be abandoned now.
The C++ committee (rightly so, I think) tends to prefer library-based solutions whenever possible, because there's less chance of disruptive changes when you add new libraries. Only when a library solution won't work do they turn to new language features. You'll also notice they really don't like adding new keywords at this point.
A lot of people seemingly don't understand how important this backwards compatibility is (presumably because they're always rewriting stuff using the latest new-and-shiny tech), but there are many places that have code that's decades old. It's a terrible idea to go and tinker with robust, well-tested code just because it's not the latest new-and-shiny. The careful attention to backwards-compatibility causes a lot of issues (like slow compile time / language complexity, etc), but it's also one of C++'s greatest strengths. People know that an investment in C++ code will be working just fine for decades to come. I mean, they're just now depreciating trigraphs, for pete's sake. Apparently IBM still has code that uses those and opposed their removal in the last standards round, but they're a tiny minority and couldn't sway the committee this time. No one else even knows what the hell they are.
Look how much of a rift the Python 2 to 3 change caused. Even if it's good for the language, incompatible changes that occur too quickly can cause real problems for a programming community. Even after 8 years, a significant percentage of Python programmers are still using 2.x instead of 3, mostly because of dependencies holding them back.
Nothing would kill new C++ features faster than incompatibility with legacy code. And in fact, one of the nice things about C++ is that it typically allows programmers to start adding those new features piecemeal as they get more familiar with them and as they get compiler support.
Irony: Agile development has too much intertia to be abandoned now.