C++ Ecosystem in 2022: Fast Adoption of C++17 and C++20, C++ Toolset Landscape, and Better Code Analysis Practices
The results of the sixth annual survey conducted by JetBrains to capture the landscape of the developer community are now available! The study was carried out in May – July 2022, and we collected answers from nearly 30K developers worldwide. Among them there were 2950 developers who chose C++ as one of their three primary programming languages, and 1396 who chose C. We also managed to extract data for the group of Embedded and Game C++ developers and see if overall trends for the language varied among these groups.
We built a report based on the collected data and asked several community members to comment on it. This year we got the chance to talk to the following people:
- Guy Davidson, Head of Engineering Practice, Creative Assembly
- Jason Turner, C++ Trainer, Speaker, Author, and YouTuber
- Titus Winters, Principal Engineer at Google
In this post we’ll discuss the final results, review the trends, and learn which direction the C++ community is currently evolving in. We also invite you to read through the key takeaways and detailed data for many programming languages and areas of software development:
C++ standard: developers are moving fast to C++17 and C++20
What is currently the most widely used C++ standard? Are C++ developers planning to migrate in the next 12 months, and if so, what will they migrate to? We can definitely see the latest C++ standards growing in popularity. C++17 is the most widely used and C++20 is growing fast, while everything pre-C++14 has dropped since 2021.
Neary half of the respondents for each language version don’t plan to migrate to a newer language standard. However, it’s promising to see many developers aiming to upgrade to C++20:
- 16% of those who are on C++98/C++03
- 26% of those who are on C++11
- 29% of those who are on C++14
- 53% of those who are on C++17
Guy, Jason, Titus, what do you think about the trends?
Titus: I’m very glad to see that the solid majority of users are on releases from the last 5 years. Also, seeing the pre-C++11 releases drop below 10% is good news. Another couple years and we can stop including those in these sorts of surveys!
Jason: I’m really surprised to see the rate of C++20 adoption. Things are clearly changing. We’re seeing a much faster adoption of new standards than we had in the past. As for the migration, I find this particularly surprising, since I’m not seeing very many companies ask for C++20 training yet. Many people still feel lucky to be moving to C++17.
Guy: It’s great to see migration steadily improving. I am especially heartened to see game developers embracing C++20, and I look forward to support from all game platforms. It will be a challenge for the vendors to implement, but I am sure it will be worth it for concepts and ranges alone.
Surveys like this remind us to write code that works everywhere, not just on the latest standard. That can be quite a trial (look at ranges-v3, which supports the last three standards) but is the best way to get your library in front of the largest audience.
Regarding the big-3 features of C++20, the trends changed in interesting ways. A year ago Modules was the top feature C++ developers were planning to start using in the next 12 months. However, probably due to the state of support for C++20 modules in tooling, Concepts took the top spot instead. At the same time, 2022 can be called the year when Modules got the best treatment from the tooling:
- In 2022, CMake released support for C++ modules and it’s now available for v3.25 and later.
- C++20 modules were added to ReSharper C++ and CLion.
What’s up with C++ tooling
CMake – Stockholm Syndrome for C++ Engineers
We noticed a trend a couple of years ago that saw CMake steadily growing year over year, and it showed no signs of stopping in 2022. While Bazel, Meson, Scons, Qmake, and some other build systems are still around, the top 3 remain unbeatable – CMake, MSBuild (Visual Studio), and Makefiles.
Guy: I am on record as likening CMake to Stockholm Syndrome for C++ Engineers. It has become the de facto standard, for better or worse, as demonstrated by the clear lead it holds over its competitors. The introduction of native CMake support to Visual Studio probably made this inevitable. However, I recently read a great book on CMake by Berner and Gilor and I am starting to come round to it.
In the embedded area, Makefiles has a stronger position than MSBuild (43% vs 29%), as many hardware vendors are still using it widely and not moving to CMake as fast as general C++ projects. In game development, it’s the other way around (49% vs 33%), which is also expected, given the strong connection of game development to the Windows and Visual Studio ecosystems.
Hopes for a package management solution
We totally agree with Titus that the state of dependency management approaches in C++ world is sad compared to many other languages.
Titus: Dependency management and package management make me sad. The value of reproducible builds and clear dependency chains is massive. There’s so much “it happens to work” in this space.
For the majority of C++ developers (25%), library code is still a part of their build. Given the variety of build systems available for C++ developers, building libraries within your own project can get tricky. Fewer people (24%) compile libraries separately using their own instructions. And the portion of people who use system package managers is lower, at only 21%.
Guy: The continuing situation with packaging C++ code for third party consumption is reflected here. Building third-party code from source yourself and using your own command line switches with complete visibility of what is going into your binaries is infinitely preferable to compromising on, for example, using exceptions or RTTI. I look forward to this problem being solved, but I have no optimism for that happening.
However, vcpkg and Conan are now constant members of the ecosystem:
It looks as though, with slightly wider tooling adoption, they might become preferred ways of managing dependencies in C++ projects. To help with that, CLion adds support for vcpkg in the 2023.1 version, which is now in early preview. The Conan/JFrog team maintained their plugin for CLion for a while, however it seems to have been abandoned a couple of years ago.
26% of developers still don’t write unit tests
While Google Test seems to be unbeatable for C++ developers, there are lots of interesting changes happening for other types of answers. The number of developers not doing any unit tests at all is dropping (Finally!).
Titus: The statistic saying that a quarter of developers aren’t writing unit tests freaks me out. I don’t feel strongly about how you express those or what framework you use, but we all do need to be writing tests.
Guy: Engineers much prefer writing code to tests for that code, and the time spent writing tests outweighs any real long-term benefits.
Catch/Catch2 keeps growing, even though its move away from the header-only framework in v3 was questionable to many C++ developers who considered header-only to be a main benefit. Maybe doctest will be their next choice?
Code Analysis
When we talk to our respondents about the code analysis tools they rely on, there are two major groups that can be identified: one-third of respondents who rely on the code checkers provided or integrated into their IDEs, and one-third who don’t use any code analysis tools at all. All the other tools – including the trending Clang-based tools, or other checkers like CppCheck, SonarSource linters, PVS-Studio, or Coverity – have smaller shares. This gives us the feeling that C++ developers don’t usually go out of their way to include code analysis tools in their toolsets, even if those tools are not already integrated into their main coding tools. This puts an extra responsibility on tool creators like JetBrains, because we have to make sure our tools deliver the most useful integrations, and we have to onboard the tools into our IDEs. CLion comes with Clang-Tidy and Clang analyzer integrated, while other vendors like SonarSource or PVS-Studio provide plugins for CLion.
Guy: This is a topic close to my heart, since I wrote a book on the C++ guidelines. Mechanical static analysis is improving all the time, and I am delighted to see people taking it seriously. With only 30% of people avoiding static analysis, I am reasonably confident that open-source code will become increasingly safe and secure.
In 2022 we also decided to figure out at which development stages the code analyzers are usually applied. Nearly half of the respondents said they simply use the compiler checks during the project compilation stage. More interestingly, 26% have code analysis as part of their CI/CD pipelines. This is what SonarSource is promoting with their tools. JetBrains is also working towards bringing code analysis to the CI/CD stage with Qodana. Would you be interested in getting CLion C++ linters in Qodana? Let us know in the comments!
In addition, one-fifth of the respondents mentioned dynamic analysis as their code quality practice. Here’s what Guy thinks about it:
Guy: Of course, static analysis isn’t the only option, and it is pleasing to see that dynamic analysis features here as well. Putting it into the compiler shifts left almost as far as possible: real-time syntax highlighting at edit time would be the only way to shift it further left.
On the subject of the compilation stage, it’s interesting to see which tools or techniques C++ developers use to optimize their C++ project build times. This is also a new question we added in 2022, so there’s no timeline to explore, and we’re limited to the 2022 results:
Small is beautiful
The majority of developers state they are optimizing their includes and dependencies. But how do they do it? In ReSharper C++, we have the includes analyzer which attempts to estimate the contribution of each header file to the build time based on the number of lines of code that it adds to the total compilation workload. This might be just one way of solving the problem. We are very interested in learning the techniques and tools C++ developers use for such optimizations. Share your experience in the comments!
30% of developers use PCH, and 15% switched to modules to address this building times problem. This looks really promising to us! Here is Guy’s take on the topic:
Guy: Despite the raft of tools available for this job, making the code better in the first place is the obvious and most popular approach. Small is beautiful in this case. I will be interested to see how precompiled headers and modules interact in the coming year or so, similarly with unity builds. I think there is still plenty of research to be done in distributed building as IncrediBuild does, and I look forward to improved caching.
That’s it! Check out the full report and let us know which trends you find the most interesting and exciting, and which ones you are a little disappointed with, if any.
The JetBrains C++ team
The Drive to Develop
Subscribe to CLion Blog updates
