Chapter 6. The Future of C++
We don’t claim any particular gifts at seeing the future, but we can peak at where the standard is going, and then we’ll point out some of the trends that we see today that we think will continue to be important, perhaps even more important in the future.
Setting the Standard
What will be in C++17? Of course we won’t have a complete answer until it is finished, but we can get a hint about where the language is going by looking at what the committee is working on now. One clue is to look at the working groups that were formed after the 2011 release and what they are working on.
The new groups include:
- Concurrency
-
Multithreading libraries have always been a part of C++, but only with the 2011 release has concurrency been part of the standard. But concurrency is a huge topic, and only basic building blocks were provided in C++11/14. There is room for standard thread pool and other concurrency tools. This is also the group that looks at vectorization and how to exploit GPUs, a much needed enhancement to C++.
- Modules
-
The header-based include model needs to be replaced by a system that explicitly defines what a module wants to make public. This can support dramatically faster builds and better encapsulation of libraries.
- File System
-
It currently isn’t possible to read the contents of a directory in a standard portable way. This group is looking at the Boost FileSystem library.
- Networking (Inactive1)
-
Currently all networking done in C++ (and there is a lot) is done with nonportable libraries. It is time that networking is part of the standard.
- Transactional Memory
-
The future is concurrency, but “locks” don’t compose or scale. Transactional memory is one possible solution.2
- Numerics
-
Fortran is often seen as the language of choice for programs requiring extensive numeric computations, particularly if matrixes are required. The Standards Committee isn’t willing to cede this domain.
- Reflection
-
C++ reflection is limited. It is likely to continue to be restricted to compile time, but there are a lot of opportunities for improvement even with this limitation.
- Concepts
-
Investigating how to define constraints on types used in generic programming.
- Ranges
-
Investigating how to update the standard library with a range concept rather than iterator pairs and how to extend this to include containers and range-based algorithms.
- Feature Test
-
Standard features are rolled out as fast as tool vendors can provide them. This group is looking at how to define a portable standard way to check for the presence of new features.
- Databases (Inactive3)
-
Database-related library interfaces.
- Undefined and Unspecified Behavior
-
This group is reviewing all the areas that the standard calls out as undefined or unspecified behavior in order to recommend a set of changes to how these are called out.
- I/O
-
This group is looking into standardizing low-level graphic/pointing I/O primitives.
One of the committee’s highest priorities is backward compatibility. Any existing standard-compliant code must continue to compile and mean the same thing after any change to the standard.
The practical implication of this is that the committee (and the broader community) must live forever with any errors in the standard.4 Any feature released in the standard will have code written that relies on that feature as specified. If that feature was specified incorrectly, correcting it in a subsequent standard would break existing code. In general, proposals that break existing code are non-starters with the committee.
Making this even more difficult is the fact that for some features, real-world experience is the only good way to know the best way to specify the feature. To address the problem, the committee is beginning to use technical specifications (TS).5 A TS is way of releasing a set of features (either core language, library, or both) that are considered standard-candidate material.
Tool vendors can implement a TS and provide it to users as a non-standard extension for experimental use. This allows the committee to gather real-world user experience before adding the feature to the standard.
How well does this process work? Well, we don’t know yet.6 In order for the TS approach to work, vendors must implement, and users must experiment with each TS released.7 This seems very likely, but only one TS has been released,8 and it is too early to know how this will work out.
Here are the technical specifications that are currently in pipeline:
- File System
-
Work based on Boost.Filesystem v3, including file and directory iteration.
- Library Fundamentals
-
A set of standard library extensions for vocabulary types like optional<> and other fundamental utilities.
- Networking
-
A small set of network-related libraries including support for network byte order transformation and URIs.
- Concepts
-
Extensions for template type checking.
- Arrays
-
Language and library extensions related to arrays, including runtime-sized arrays and
dynarray<>. - Parallelism
-
Initially includes a Parallel STL library with support for parallel algorithms to exploit multiple cores, and vectorizable algorithms to exploit CPU and other vector units.
- Concurrency
-
Initially includes library support for executors and non-blocking extensions to
std::future. Additionally may include language extensions likeawait, and additional libraries such as concurrent hash containers and latches. - Transactional Memory
-
A promising way to deal with mutable shared memory that is expected to be more usable and scalable than current techniques based on atomics and mutexes.
There is absolutely no guarantee that any of these will be in the 2017 standard.9 But knowing that this is what the committee is working on gives us a sense of its priorities and ambition for the evolving standard for C++.
“Never Make Predictions, Especially About the Future” (Casey Stengel)
Stein’s Law is that trends that can’t continue won’t.10 The trick is to figure out which trends will continue indefinitely. Here are some that we see.
Performance
Mobile and cloud computing has rekindled the interest in performance, and we think performance will always be important. No computer will ever be powerful or energy efficient enough that performance won’t matter, at least for some very important applications. This looks good for a language that has always been uncompromising in its approach to performance.
New Platforms
As the cost of hardware falls, more and more computing devices will be created. These new devices will mean new environments, some with very tight memory footprint requirements. This looks good for a highly portable systems language with a “you don’t pay for what you don’t use” approach to features.
Scale
At the top end, the falling cost of hardware will lead to the design and implementation of systems of a size that are difficult for us to imagine now. To implement these systems, engineers are going to look for a language that scales with additional users and teams and supports the creation of very large systems. Such a language will need to have high performance, but also support the high-level abstractions necessary to design systems at that scale. It will also need as much compiler-aided bug-catching as possible, which is heavily aided by an expressive type system that C++ supports.
Software Ubiquity
Our world is going to be more and more one in which we are surrounded by software. Will all of this software need to be highly portable, low-memory, high-performance code? Of course not. There will be great demand for applications that do not require software to be pushed to the limit. But these applications will always run on infrastructure where performance will be in demand. A lot of this infrastructure is currently written in C, but when infrastructure code requires high-level abstractions, that code is and will usually be written in C++.
It may be that the software industry as a whole will grow faster than the C++ community and that shrinking market share may make C++ appear to be less important. But the fact is that high performance infrastructure makes it possible to create applications in a less demanding programming environment. More programmers working in high-level, nonsystems languages just increases the demand for and value of the systems-programming projects that make their work possible.
Powerful Tools
The philosophy of C++ has been to rely more and more on a powerful compiler to do the heavy lifting of making high-performance applications. At times, that has pushed our compilers to the breaking point.11 We think this is the correct direction for tool development: designing tools that let programmers focus on expressing their ideas as clearly as possible, and let the tools do the hard work to implement these ideas efficiently.
We will see the language definition evolve toward making more demands on the compiler. We’ll also see more and more creative tools built with the Clang toolkit.
The world of computing technology can change quickly, dramatically, and sometimes unexpectedly, but from where we sit, it looks like C++ is going to continue to play an important role for the foreseeable future.
1 Its work is complete.
2 http://research.cs.wisc.edu/trans-memory/
3 Currently handled directly by Library Evolution working group.
4 We are looking at you, vector<bool>.
5 The difference between an ISO Technical Report, of which the Committee released one in 2005, and an ISO Technical Specification, which will be used by the Committee going forward, is not very interesting. The TR1 should probably have been released as a TS.
6 It worked well with the TR1 from 2005 that was incorporated into the 2011 release with some minor changes. But that was library-only, and almost all of it was already implemented and in wide usage as Boost libraries.
7 The approach will also fail if users embrace the TS in such a way that it becomes a de facto standard of its own.
8 File System
9 There is not even any guarantee that next standard will be released in 2017.
10 “If something cannot go on forever, it will stop." — Herbert Stein
11 Early users of code that pushed the envelope on templates sometimes found that their compilers seemed to grind to a halt. Advances in compiler technology and computing power generally overcame this limitation.