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 that they were, “scripting” languages for script kiddies. 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 programmers have to resort to seeking advice on what constitutes a “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 stuff, but the majority will be mystified. This is a strange situation and it is mostly due to C++ becoming increasingly functional.

The new variant type is a bit of a throwback to its C roots. 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.

The if constantexpr statement is also new, 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 of the type inference.

A more down to earth changes relate 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 an = in an if.