Compiler statistics reveal more than which executable developers run. They also show how C and C++ teams choose language standards, organize builds, manage libraries, and apply diagnostics. The 2025 JetBrains survey covered 1,800 C++ developers across 22 countries, while the Clang figures below describe implementation status in official tables accessed on September 30, 2026. Survey percentages are not global compiler market share and may be somewhat skewed toward JetBrains-product users.
Contents
- Compiler choices among C++ developers
- C++ standard adoption and migration
- Build systems and dependency practices
- Clang support for C language standards
- Clang support for C++ standards
- Versioned C and C++ features
- Diagnostics and code-quality tooling
Compiler choices among C++ developers
The JetBrains survey shows a multi-compiler environment rather than a single dominant choice. GCC was regularly used by 70% of surveyed C++ developers in 2025. Clang was regularly used by 45%, and MSVC by 27%. Because respondents could use more than one compiler, these percentages describe regular use across projects, not mutually exclusive market shares. The State of C++ 2025 is the source for all figures in this section.
Several additional tools occupied smaller but meaningful portions of the survey. The clang-cl driver was regularly used by 12% of respondents, while Intel C++ Compiler Classic reached 7%. Keil compilers were regularly used by 5%, and Intel LLVM by 4%.
| Compiler or driver | Regular use among surveyed C++ developers, 2025 |
|---|---|
| GCC | 70% |
| Clang | 45% |
| MSVC | 27% |
| clang-cl | 12% |
| Intel C++ Compiler Classic | 7% |
| Keil compilers | 5% |
| Intel LLVM | 4% |
The survey population matters when interpreting the ranking: it consisted of 1,800 C++ developers across 22 countries. The results indicate how this respondent group used compilers regularly; they should not be read as a census of every C or C++ installation, embedded toolchain, or commercial deployment.
C++ standard adoption and migration
C++17 was the most commonly used standard in the 2025 survey, reported by 43% of surveyed developers. C++20 followed at 34%, while C++11 was reported by 24%. C++23 reached 21%, C++14 reached 16%, and C++98 or C++03 reached 9%. C++26 was reported by 7%, and 12% of respondents were unsure which standard they regularly used. These figures come from The State of C++ 2025, and the categories are regular-use responses rather than a calculated distribution of all C++ code.
| C++ standard | Regular use among surveyed developers, 2025 |
|---|---|
| C++17 | 43% |
| C++20 | 34% |
| C++11 | 24% |
| C++23 | 21% |
| C++14 | 16% |
| C++98 or C++03 | 9% |
| C++26 | 7% |
| Unsure | 12% |
The survey also measured why teams do or do not migrate. A current standard was considered sufficient for their tasks by 71% of surveyed C++ developers. Older compiler or library dependencies prevented migration to a newer standard for 28%, while 17% cited insufficient time or resources. Those responses place compiler compatibility in a wider engineering context: adoption depends not only on a standard’s features, but also on the age of the toolchain and the libraries around it.
The standard figures should not be added together. A developer can regularly use more than one standard across projects, and the survey’s response categories do not establish a single exclusive standard for every respondent. They are best used as indicators of adoption patterns in the surveyed population.
Build systems and dependency practices
CMake was regularly used by 59% of surveyed C++ developers in 2025, making it the most frequently reported build-system choice in this dataset. Visual Studio project files were used by 34%, and Makefiles by 27%. Ninja reached 15%, followed by Xcode projects at 9%, Gradle at 8%, and qmake at 4%. These are regular-use percentages from The State of C++ 2025, not exclusive project shares.
The dependency figures show a similarly mixed workflow. A system package manager was used to manage C++ libraries by 36% of surveyed developers. Another 35% included library source code directly in their builds, while 24% compiled libraries separately using the libraries’ own instructions. Teams can use several of these approaches, so the figures describe practices that coexist rather than a single package-management hierarchy.
The relationship between compiler statistics and build statistics is practical. A compiler upgrade can affect a CMake configuration, a Visual Studio project, a Makefile, or a separately built dependency differently. The survey does not quantify failure rates or migration time, but it does show that build and library decisions are part of the environment in which compiler changes occur.
Clang support for C language standards
The official Clang C language status table, accessed on September 30, 2026, records support by language mode and minimum version. Clang supports C23 mode beginning with Clang 18, using the -std=c23 option. C2y mode begins with Clang 19 and uses -std=c2y.
For earlier C standards, the same status table lists C17 support beginning with Clang 6. The mode is available through -std=c17 or -std=c18. Clang implements all of ISO C99, with C99 mode available through -std=c99. C89 mode is also supported, and the table marks it as available without a minimum version.
These entries are implementation-status measurements, not adoption percentages. A mode being available from a particular compiler version does not establish how many projects use it, nor does it mean every library or platform combination has identical behavior. The official table distinguishes its own support labels and version information; those distinctions should remain separate from survey data about developer behavior.
Clang support for C++ standards
The official Clang C++ language status table, accessed on September 30, 2026, reports that Clang 5 and later implement all features of ISO C++17. Clang 16 and later build C++ code according to C++17 by default. The difference between implementation support and a default language mode is important: a compiler can implement a standard before using it as the default for ordinary compilation.
The table also reports complete ISO C++14 implementation in Clang 3.4 and later, and complete ISO C++11 implementation in Clang 3.3 and later. Clang implements ISO C++98/C++03 except for export, which was removed in C++11. These are statements about Clang’s documented language support, not claims that all C++17, C++14, C++11, or older codebases have migrated.
When comparing the survey with the status table, the measures answer different questions. The JetBrains figures describe regular use among a defined survey population in 2025. The Clang table describes compiler capability and defaults as recorded on September 30, 2026. Neither source converts directly into the other.
Versioned C and C++ features
The Clang C status table records several version-specific C23 additions. Clang 19 added support for the C23 #embed feature, while Clang 18 added C23 type inference for object declarations. Clang 19 also added C23 constexpr object definitions. The C23 nullptr constant was added in Clang 17, and improved normal enumerations in C23 were added in Clang 20. Clang 18 added free positioning of labels inside compound statements in C23. These details are reported in Clang’s C language status table, accessed on September 30, 2026.
The C++ status table lists a separate sequence of feature support. Clang 18 added support for the C++23 deducing-this feature. Clang 17 added C++23 consteval-propagation support, Clang 15 added the C++23 multidimensional subscript operator, and Clang 14 added the C++23 if consteval feature. For C++20, Clang 10 added support for concepts and for the three-way comparison operator. The source for these implementation-status measurements is Clang’s C++ language status table, accessed on September 30, 2026.
The version numbers identify the Clang release in which the supplied status table records support. They are not forecasts, and they do not quantify the percentage of projects using a feature. They also should not be treated as a substitute for checking a project’s complete compiler, standard-library, and platform requirements.
Diagnostics and code-quality tooling
Compiler workflows extend into formatting, static analysis, IDE assistance, and organizational style. In the 2025 JetBrains survey, ClangFormat was used by 29% of surveyed C++ developers for code guidelines or quality. IDE-provided tools or features were used by 28%, and Clang-Tidy by 27%. Clang Static Analyzer reached 22%.
Other tools appeared at lower reported levels. Cppcheck was used by 11% of surveyed developers. SonarLint, SonarQube, or SonarCloud was used by 7%, and Coverity by 5%. The Google C++ Style Guide was followed by 31%. All of these figures are regular-use or reported-practice percentages from The State of C++ 2025, and multiple tools or guidelines can apply to the same team.
Together, the measurements show that compiler choice is only one part of a C++ development system. GCC, Clang, and MSVC lead the reported compiler choices, while CMake leads the listed build-system practices. Standard adoption remains distributed across C++17, C++20, C++11, and newer or older modes. Official Clang tables then add a version-specific view of what the compiler implements for C and C++, while formatting and analysis tools show how teams put those capabilities into a broader code-quality process.