C++ 调研结果：C++17 和 C++20 正被快速采用、C++ 工具集格局 | 2022 开发者生态系统现状
引入
JetBrains 为反映开发者社区状况而开展的第六次年度调查的结果现已公布！研究于 2022 年 5 月至 2022 年 7 月进行，收集了全球近 3 万名开发者的回复。其中有 2950 名开发者选择 C++ 作为三种主要编程语言之一，1396 名开发者选择 C。我们还提取了嵌入式和游戏 C++ 开发者组的数据，了解语言的总体趋势在这些群体中是否有所不同。
我们根据收集到的数据构建了一份报告，并邀请了几位社区成员发表评论。今年，我们有幸采访了以下人员：
Guy Davidson，Creative Assembly 工程实践主管
Titus Winters，Google 首席工程师
在这篇博文中，我们将讨论最终结果、回顾趋势并分析 C++ 社区目前的发展方向。我们也邀请您阅读许多编程语言和软件开发领域的关键要点和详细数据：
查看完整报告
开发者正在快速转向C++17和C++20
目前使用最广泛的 C++ 标准是什么？C++ 开发者是否计划在未来 12 个月内迁移？如果是，将迁移到什么版本？最新的 C++ 标准绝对会越来越受欢迎。 C++17 使用最广泛，C++20 增长迅速，而自 2021 年以来，C++14 之前的所有语言都有所下降。
每个语言版本都有近一半受访者不打算迁移到较新的语言标准。不过，也有希望看到许多开发者升级到 C++20：
C++98/C++03 使用者中有 16%
C++11 使用者中有 26%
C++14 使用者中有 29%
C++17 使用者中有 53%
我很高兴看到绝大多数用户都在使用过去 5 年的版本。另外，C++11 之前的版本下降到 10% 以下也是个好消息。再过几年，我们就可以停止把它们添加到调查了！
Titus
C++20 的采用率让我相当惊讶。情况显然正在发生变化。可以看到，采用新标准的速度比过去快得多。至于迁移，这让我特别惊讶，因为我还没有看到很多公司要求 C++20 培训。许多人仍然对迁移到 C++17 感到幸运。
Jason
很高兴看到迁移稳步推进。我特别高兴看到游戏开发者接受 C++20，我期待所有游戏平台的支持。供应商实现起来将是一个挑战，但我相信，仅就概念和范围而言这都是值得的。
这样的调查提醒我们编写适用于任何地方的代码，而不仅仅是最新的标准。这可能是一个相当大胆的尝试（看看支持最后三个标准的 ranges-v3），但这是让你的库呈现给最多受众的最佳方式。
Guy
关于 C++20 的三大功能，趋势发生了有趣的变化。一年前，模块是 C++ 开发者计划在未来 12 个月内开始使用的首要功能。然而，可能是由于工具中对 C++20 模块的支持，概念反而占据了榜首。同时，2022 年也可以说是模块得到工具最好待遇的一年：
2022 年，CMake 发布了对 C++ 模块的支持，现可用于 v3.25 及更高版本。
C++20 模块已被添加到 ReSharper C++ 和 CLion 中。
CMake – C++工程师的斯德哥尔摩综合征
几年前，我们就注意到 CMake 逐年稳步增长的趋势，并且这一趋势在 2022 年没有停止的迹象。虽然 Bazel、Meson、Scons、Qmake 和其他构建系统仍然存在，但前 3 名的地位仍然不可撼动：CMake、MSBuild (Visual Studio) 和 Makefile。
我把 CMake 比作 C++ 工程师的斯德哥尔摩综合征。无论如何，它都已经成为事实上的标准，明显领先于竞争对手。Visual Studio 引入原生 CMake 支持可能使这种情况不可避免。不过，最近读过 Berner 和 Gilor 写的关于 CMake 的好书后，我开始接受它了。
Guy
在嵌入式领域，Makefile 的地位比 MSBuild 更高（43% 对 29%），因为许多硬件供应商仍在广泛使用它，并没有像一般 C++ 项目那样快速转向 CMake。在游戏开发中，情况正好相反（49% 对 33%），这也在意料之中，因为游戏开发与 Windows 和 Visual Studio 生态系统密切相关。
对软件包管理解决方案的期望
我们完全同意 Titus 的观点，与许多其他语言相比，C++ 领域中依赖项管理方法的现状并不乐观。
依赖项管理和软件包管理的现状让我很难过。可重现的构建和清晰的依赖链很有价值。 这个领域有太多“碰巧有用”的东西。
Titus
对于大多数 C++ 开发者 (25%)，库代码仍然是其构建的一部分。鉴于可供 C++ 开发者使用的构建系统多种多样，在您自己的项目中构建库可能会较为棘手。更少的人 (24%) 使用自己的指令单独编译库。使用系统软件包管理器的人比例更低，只有 21%。
这里反映了为第三方使用打包 C++ 代码的情况。 自己从源代码构建第三方代码并使用自己的命令行开关，完全了解二进制文件中的情况，这比在使用异常或 RTTI 等内容时妥协要好得多。我期待这个问题得到解决，但我并不乐观。
Guy
但是，vcpkg 和 Conan 现在是生态系统的固定成员：
看起来，随着工具的采用范围稍微扩大，它们可能会成为 C++ 项目中管理依赖项的首选方式。为此，CLion 在 2023.1 版本中添加了对 vcpkg 的支持，该版本目前处于早期预览阶段。Conan/JFrog 团队为 CLion 维护了一段时间的插件，但它似乎在几年前就被放弃了。
26%的开发者仍然不编写单元测试
虽然 Google Test 在 C++ 开发者中的地位似乎不可撼动，但其他类型的答案还是发生了许多有趣的变化。完全不做任何单元测试的开发者的数量正在下降（终于！）。
四分之一的开发者不编写单元测试的统计数据让我很吃惊。我不太在乎你如何表达或使用什么框架，但我们都需要编写测试。
Titus
工程师更喜欢编写代码而不是为这些代码编写测试，而且编写测试花费的时间超过真正的长期收益。
Guy
Catch/Catch2 一直在增长，尽管它在 v3 中脱离纯标头框架的做法对许多认为纯标头是主要优点的 C++ 开发者来说是有疑问的。也许 doctest 会成为他们的下一个选择？
我们与受访者谈论依赖的代码分析工具后，确定了两大组：三分之一的受访者依赖提供或集成到 IDE 中的代码检查器，三分之一的受访者完全不使用任何代码分析工具。其他工具 – 包括流行的基于 Clang 的工具，或其他检查器，如 CppCheck、SonarSource linter、PVS-Studio 或 Coverity – 占比较小。这让我们感觉 C++ 开发者通常不会特意在工具集中增加代码分析工具，即使这些工具尚未集成到主要编码工具中。这让 JetBrains 之类的工具创建者需要负起额外的责任，因为我们必须确保工具提供最有用的集成，也必须将这些工具集成到 IDE 中。CLion 集成了 Clang-Tidy 和 Clang 分析器，而 SonarSource 或 PVS-Studio 等供应商则为 CLion 提供插件。
这是我很关心的一个话题，我写过一本关于 C++ 准则的书。机械静态分析一直在改进，我很高兴看到人们认真对待它。只有 30% 的人避免静态分析，我有理由相信开源代码将变得更加安全。
Guy
2022 年，我们还决定理清代码分析器通常应用在哪些开发阶段。近一半的受访者表示只在项目编译阶段使用编译器检查。更有趣的是，26% 的受访者将代码分析作为其 CI/CD 管道的一部分。这就是 SonarSource 通过他们的工具所推广的。JetBrains 还致力于通过 Qodana 将代码分析引入 CI/CD 阶段。您有兴趣在 Qodana 中获取 CLion C++ linter 吗？在评论中告诉我们吧！
此外，五分之一的受访者提到动态分析是其代码质量做法。这是 Guy 的看法：
当然，静态分析不是唯一的选择，很高兴看到动态分析功能也在这里。 将其放入编译器中时，几乎会尽可能向左移动：编辑时实时高亮显示语法是将其进一步向左移动的唯一方式。
Guy
关于编译阶段，看看 C++ 开发者使用了哪些工具或技术来优化 C++ 项目构建时间。这也是我们在 2022 年添加的新问题，因此没有时间线可供探索，仅限于 2022 年的结果：
大多数开发者表示正在优化 include 和依赖项。但他们是怎么做的？在 ReSharper C++ 中，我们有 include 分析器，它会根据每个头文件添加到总编译工作负载的代码行数来估计每个头文件对构建时间的影响。这可能只是解决问题的其中一种方式。我们非常有兴趣学习 C++ 开发者用于此类优化的技术和工具。
30% 的开发者使用 PCH，15% 改用模块来解决这个构建时间问题。这在我们看起来很有前景！这是 Guy 对这个话题的看法：
尽管有大量工具能胜任这项工作，但直接改进代码是显而易见也最受欢迎的方式。在这里，小即是美。我有兴趣关注预编译头文件和模块在未来一年左右的互动，Unity 构建也是一样。我认为像 IncrediBuild 一样，在分布式构建中还有很多研究要做，我期待的是缓存改进。
Guy
查看完整报告
本博文英文原作者：Anastasia Kazakova
相关阅读：历年开发者生态系统现状报告
⏬ 戳「阅读原文」查看完整版调研报告