Question

与其他语言相比，在 1990 年代初期到中期，C++ 在用于工业用途的工具和编程环境方面做得相当不错。例如，图形用户界面和集成软件开发环境都率先应用于 C++。后来，开发和投资的重点转移到专属语言，例如 Java（Sun）、C#（微软）和 Objective-C（苹果）以及更简单的语言，例如 C（GNU）。

在我看来，有两个主要原因：

• 资金：组织倾向于使用他们可以控制的语言和工具，从而提供比竞争对手更大的差异化优势。从这个角度来看，C++ 由正式的标准委员会控制、强调所有人的利益，这反倒成了一个缺点——某种公地悲剧的变体。
• 宏和文本定义：C++ 没有一个简单，可广泛使用的内部表示形式来简化基于源代码的工具构建，并且大量使用宏必然导致程序员看到的跟编译器所分析的有所不同。和 C 一样，C++ 是根据字符序列来定义的，而非根据直接表示抽象且更易于操作的构件来定义。我与 Gabriel Dos Reis 一起定义了这样一个表示形式 [Dos Reis and Stroustrup 2009, 2011]，但事实证明 C++ 社区中面向字符的传统难以克服。当初建造时没有意识到的规范化结构，想通过翻新加上去就难了。

因此，在 2006–2020 年期间，与其他语言相比，C++ 被支持工具方面的问题严重困扰。但是，随着以下这些工具的涌现，这种情况得到了稍许改善：

• 工业级的集成软件开发环境：例如微软的 Visual Studio [Microsoft 2020; VStudio Wikipedia 2020] 和 JetBrains 的 CLion [CLion Wikipedia 2020; JetBrains 2020]。这些环境不仅支持编辑和调试，还支持各种形式的分析和简单的代码转换。
• 在线编译器：例如 Compiler Explorer [Godbolt 2016] 和 Wandbox [Wandbox 2016–2020]。这些系统允许从任何浏览器中编译 C++ 程序，有时甚至可以执行。它们可用于实验，检查代码质量，还有比较不同的编译器及编译器和库的不同版本。
• GUI 库和工具：例如 Qt [Qt 1991–2020]、GTKmm [GTKmm 2005–2020] 和 wxWidgets [wxWidgets 1992–2020]。不幸的是，Qt 依赖于元对象协议（meta-object protocol，缩写为 MOP），因此 Qt 程序还不是标准的 ISO C++ 应用。静态反射（§9.6.2）使我们最终能够解决这个问题。C++ 社区的问题不是没有好的 GUI 库，而是太多了，因此会有选择困难。
• 分析器：例如 Coverity [Coverity 2002–2020]，Visual Studio 的 C++ Core Guidelines 分析器（§10.6）和 Clang Tidy [Clang Tidy 2007–2020]。
• 编译器工具支持：例如 LLVM 编译器后端基础设施，可简化代码生成和代码分析 [LLVM 2003–2020]。除了 C++ 本身，这为许多新语言提供了福利。
• 构建系统：例如 build2 [Build2 2014–2020] 和 CMake [CMake 2000–2020]，以及 GNUmake[GNUmake 2006–2020]。同样，在没有标准的情况下，选择会有困难。
• 包管理器：例如 Conan [Conan 2016–2020] 和 vcpkg [vcpkg 2016–2020]。
• 运行时环境：例如 WebAssembly：将 ISO C++ 编译为字节码以在浏览器中部署的系统 [WebAssembly 2017–2020]。
• 运行时编译、JIT 和链接：例如 Cling [Cling 2014–2020; Naumann 2012; Naumann et al. 2010] 和 RC++ [RC++ 2010–2020]。

上面列出的只是一些示例。像往常一样，C++ 用户面临的问题是可选方案的数量众多，例如：[RC++ 2010–2020] 列出了 26 个用于在编译时生成代码的系统，并且有数十个程序包管理器。因此，我们需要的是某种形式的标准化。

截至 2020 年，工具仍不是 C++ 的强项，但我们正在大范围内取得进展。