In a recently released and, by his own admission, far too long paper, C++ creator Bjarne Stroustrup tries to come up with an explanation for the overwhelming success of the programming language and has some thoughts on how to secure it.

Despite well-financed competition, fresh programming models, and new application domains, C++ was apparently able to grow its user community from about 3 million developers in 2006 to about 4.5 million devs in 2020. Stroustrup uses this as an opportunity to take a 168-page dive through the last 14 years of the (by his own estimates) over 40-year-old language. 

In “Thriving in a Crowded and Changing World: C++ 2006–2020”, he examines the features that did and didn’t make their way into the last releases, describes the standardisation process, and flags up what needs more work, before taking a look into the future. 

While you could start to wonder how “anything constructive ever emerges” when following Stroustrup through the emergence of the last four iterations of the standard, his critique and outlook are especially worth a read. It’s clear to Stroustrup that C++’s technical success is down to filling a “niche” for hardware efficient, complex applications. But more needs to be done to future-proof his creation.

One example for this is education. According to Stroustrup, “The C++ taught today is still mostly outdated and backwards looking.” 

At least, he adds, “the sorry state” C++ education is in has been recognised in the last couple of years, leading to new resources and forays into different media in order to help people in the industry master the language”. However, “most students emerge from universities with only weak and inaccurate understanding of C++ and the key techniques for using it”, which leaves a lot to be desired when it comes to ways in which software as a whole can be improved.

“Good software is essential to our civilization. To manage, we need to treat software development for critical systems as seriously as we treat mathematics and physics,” the C++ creator adds, noting that if it were up to him, less crowded curricula and more time for certain topics would be one way to go, since “we would never expect to teach English in just a few months and then expect the students to appreciate Shakespeare”.

To help with that, a working group is outlining approaches to teach modern C++, while another one could become more helpful in the future and support teachers with additional tools. Which seems to be another area which could do with some work. “C++ suffered badly in the area of support tools compared to other languages”, which he puts down to the emergence of other, company backed, languages that tool providers could control better, and the way C++ is defined. The introduction of modules in C++20 is meant to help with the latter, especially when it comes to IDE support. 

A quick glance at the market shows that it isn’t really the lack of tooling that’s a problem, though fragmentation in areas like package management calls for “some form of standardization” in order to progress. A central place to find useful libraries would be helpful as well, with Boost and GitHub looking like the most promising options to become a common repository, but “there is a long way to go before a relative novice can find, download, install, and run a couple of major libraries”.

More programmers support is thoroughly needed anyway, since another problem is the cleaning up “of old messes”, says Stroustrup. This is “unpleasantly hard” and things like “the implicit narrowing conversions among the built-in types cause endless problems” while being present in billions of code lines which doesn’t lend itself to being easily changed. To Stroustrup, improved tooling in the form of static program analysis and program transformation “offers hope” in this area.

For that reason, he sees the charter of the C++ standards committee which focuses on language and library design as at least limiting. “Important topics such as dynamic linking, build systems, and static analysis have been mostly ignored. That’s a mistake. Tools are a huge part of a software developer’s world and it would be nice if they were not peripheral to language design.“

Stroustrup isn’t alone with his observations. Just as an example, the just released Developer Ecosystem overview done by IDE provider JetBrains confirms that the lack of a cross-platform package manager tends to drive people into staying away from them altogether with the rest of the user base taking pretty much whatever is available. 

The report also implies that common development practices like writing tests isn’t really something on C++ devs’ minds (30% of the asked C++ users don’t write tests), something that can definitely be ingrained into a programmer by proper training and a good way to improve software quality.

How the currently running initiatives will pan out remains to be seen. For the near future, C++23 is on the table which “boldly” suggests library support for coroutines, a modular standard library, a general asynchronous computing model, networking and progress on static reflection facilities, functional-programming style pattern matching, as well as contracts.

Other than that, Stroustrup sees promise in areas such as unicode support, support for simple graphics and user interaction, new kinds of hardware, and “exploration of improved styles and implementations of error-handling”. Stability is vital in all of this and “requires a focus on compatibility as well as resisting the urge to try to radically improve C++ by adding a multitude of ‘perfect’ features to replace imperfect or unfashionable older ways of doing things”. 

He goes on to write “new features invariably cause surprises (some pleasant, some not so pleasant) and the older features will not simply disappear”, before repeating what has been coming through all along: “Often libraries, guidelines, and tools are superior alternatives to language changes.”

Stroustrup closes with a call to simplify C++ use, since improved optimisers allow for easier code. 

His approach? “I start by chucking away the clever and complicated stuff. That’s where the bugs hide and if I have trouble understanding what’s going on, so will the compiler and optimizer. I find that this approach usually gives me modest to spectacular performance improvements, as well as simplifying future maintenance. Only if this doesn’t give me the performance I want, do I resort to advanced (aka complicated) data structures and algorithms. This is a triumph of the design of the C++ abstraction mechanisms.”