4

我有一个 C++ 软件，可以使用不同的操作系统、平台和编译器进行编译。现在有时编译器会出现错误，例如this one，这意味着 gcc 4.6.4 和 4.7.3 之前的版本是不行的。现在我可以包含一个展示错误的单元测试（也许这个问题会揭示这确实是我应该做的）但这是一项乏味的任务：编译器错误有时很难重现，将一个错误变成单元测试可能不会也很容易......这就是你手头有平台和编译器的时候。

我正在寻找的是一个存储库，它告诉我哪些版本的 g++、clang++ 和 msvc++ 存在支持 C++11 的致命错误（我不是在谈论缺少的功能，当功能不存在时我会解决它们） . 在构建系统中与它们一起构建时，我会发生致命的崩溃。不错的功能是，我什至没有被迫遇到一个错误来禁止编译器（所以我为自己节省了未来的麻烦）。

这样的清单存在吗？

4

2 回答 2

14

这可能不是您正在寻找的答案，但我相信处理这个问题的正确方法是拥有一个白名单，而不是一个黑名单。换句话说，有一个您知道可以工作的编译器列表，如果客户尝试使用与您测试过的版本不同的版本进行构建，您会在构建脚本中发出一条警告消息，内容如下：

不支持此编译器，请参阅 http://www.example.com/list_of_supported_compilers.html了解我们支持的编译器列表。如果您选择继续使用此编译器，请随意这样做，但如果您发现问题，请不要指望我们的技术支持提供全面支持。

我这么说的原因是：

  1. 您将无法证明除黑名单上的版本之外的每个版本都能正常工作。但是，无论您拥有什么测试用例，您都可以证明编译器 X 版本 abc-d 可以工作 [这并不意味着该编译器没有错误 - 只是您在测试中没有遇到任何这些错误！]
  2. 即使编译器是“已知良好的”（根据定义的任何标准），您的特定代码也可能会触发影响您的代码的错误。

任何足够大的软件（或硬件）产品都会有错误。您只能通过测试来证明您的软件有效。依赖外部“编译器 X 的某个版本中存在已知错误”不会帮助您避免影响代码的错误。话虽如此，大多数编译器都经过了很好的测试，因此您（通常）需要做一些相当不寻常/复杂的事情来使编译器失败。

于 2013-06-26T12:54:27.857 回答
4

调查Boost.Config，特别是标题<boost/config.hpp>。

这包括用于各种编译器（及其不同版本）的一大组宏，它们指示启用、损坏的 C++ 功能等。它还包括一个全面的测试套件，可用于测试任何新编译器的缺失功能等等

于 2013-06-26T15:43:14.027 回答