C++ Where Is It Heading? C++17
Written by Mike James   
Wednesday, 06 July 2016

C++ is moving really fast at the moment, well for C++. After C++14 we now have a proposal for C++17 and a new C++ every three years. Look out for C++20. So where is the language going?

Once upon a time C++ was the language that the big kids used while the rest of  the programming community looked on in awe and got on with using languages that could be regarded as, or dismissed with the idea they were, "scripting" languages for scriptkiddies.  However, compared to well designed, or designed from the ground up, languages like C# it was clear that not everything was right in the C++ camp. 

The big problem with C++ is that it is an object-oriented language grafted on top of a machine-independent, assembler-like language, i.e. C.

You have to hand it to Bjarne Stroustrup for doing a great job. As long as you keep it simple C++ is a good and reasonably modern object-oriented language that is still close enough to the machine architecture to produce programs that run about as fast as possible. This is the reason that C++ programs are often called "native" or "native code". 

The key thing about pushing C++ forward is that the new features have to be introduced in such a way that they don't break existing programs. This has resulted in a less-than-perfect development of the language, where there is often more than one way of achieving the same result. When this occurs programmer have to resort to seeking advice on what constitutes "best practice" and there isn't always consensus on this topic.

Many of the new features in C++ 14 were concerned with templates, generic programming and type inference - trendy topics. However, if you really want to make use of them, you will encounter some seemingly complicated ideas. A few C++ programmers I know have admitted to not really following the details of the new features and have hence avoided using them except in very simple situations - and preferably not at all. 

What this means is that there are a lot of C++ programmers, beginners and intermediate, who will struggle to understand what the new features are and how they can be used. The experts will be extolling the virtues of the new, but the majority will be mystified. This is a strange situation and it is mostly due to C++ becoming increasingly functional. 

A bit of a throwback to its C roots is the new variant type. This is essentially a union that is modified to be type-safe. In other words, a variant is able to hold any of the types it is declared to hold, but it only has one type at any given time and if you try to use the value as another type it will throw an exception. The example given is:

variant<int, float> v, w;
v = 12;
int i = get<int>(v);
w = get<int>(v);
try { get<float>(w); // will throw. }
catch (bad_variant_access&) {}

OK, fine, but in my experience unions are generally used when you have a bit pattern that can represent two, or even more, types of data and in such a case I don't want type safety.

Also new is if constantexpr which is evaluated at compile time and provides a way of selecting what you want to be in your code. It is designed to allow templates to be more flexible and efficient. Another template addition is the use of auto. You can now allow the type of a variable to be deduced within a template. The problem is following the rules for the type inference. 

A more down to earth change relates to assigning tuples to different variables:

auto [a , b , c] = getvalues();

and you can now declare variables in an if. This is a generalization of declaring variables in a for but really it's syntactic sugar over the block scoping of C++. For example you can write:

 if(int x = 42; true != false){}

Now this really is going to blow the mind of any beginner already confused by == and =.  I'm not sure it is worth the minor advantage for the huge loss of simplicity - never use a = in an if

C++ is the language of the wizards and, now they have control over the direction it is taking in the future, we need to worry. What makes it worse is that there is virtually no attempt by the standards setters to present a simplified case to the "grunt" programmers down here on the ground. If you don't follow the formal presentation of the spec then tough, you have no part even being here. There are a few people, Herb Sutter for example, who are trying to make things understandable, but this is hardly enough. 

For most programmers C++ 17 will happen and they will be left to cope with it.

More Information


Related Articles

Microsoft Open Sources Checked C

C++ 14 Approved

In Praise Of C++ Bjarne At ICPC

Why your next language better be C++ 

The Irrelevance of the New C++ Standard

Programming: Principles and Practice Using C++, 2nd Ed (book review)

A Tour of C++ (book review)


To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on, Twitter, FacebookGoogle+ or Linkedin



Rust Twice As Productive As C++

Google director of engineering, Lars Bergstrom, gave a talk at the recent Rust Nation UK conference and claimed that Rust was twice as productive as C++. Given how good Google is at C++, this is quite [ ... ]

Grafana 11 Improves Metrics

Grafana Labs, creators of the Grafana open-source metrics analytics and visualization suite, has announced the preview release of Grafana 11 with improvements to make it easier to view metrics, and ch [ ... ]

More News


raspberry pi books



or email your comment to: comments@i-programmer.info



Last Updated ( Wednesday, 06 July 2016 )