在 GCC 的生产环境中使用 C++11 [关闭]答案

【问题标题】：Using C++11 in a production environment with GCC [closed]在 GCC 的生产环境中使用 C++11 [关闭]
【发布时间】：2011-11-20 14:30:40
【问题描述】：

C++11 为我们提供了许多新的很棒且非常有用的工具。 GCC support of C++11 已经取得了不错的进展。所以我想过什么时候切换到C++11。这个问题只与 gcc 有关，我不希望用任何其他编译器编译我的（我们的）代码。

在 gcc 支持整个 C++11 标准以从已经实现的功能中受益之前，您会（是否）切换到 C++11？你还会在稳定性和正确性非常重要的生产环境中这样做吗？您认为只允许开发人员使用某些 C++11 功能是否合理？

您（您）将如何决定 GCC 的 C++11 支持何时可用于生产环境？

（注意：我知道this 的问题，但它与 gcc 4.4 相关，并且有些过时）

【问题讨论】：

auto 和单独的 lambdas 会让我切换。考虑到 GCC 已经支持可变参数模板 (love)，我想说，是的，切换！
绝对是的。大量的库功能经过良好测试和成熟（元组、哈希容器、智能指针），可变参数模板很棒，类型特征很棒......只是不要使用尚未实现的东西（你会立即注意到尝试编译时），并且没有理由限制对这种伟大的新语言的访问。
@Kerrek SB：我不认为元组、哈希容器或智能指针是切换的理由，因为我已经可以在没有 C++11 的情况下通过 boost 获得它们。
@GabrielSchreiber：嗯，您无需任何人携带额外的非常大且深度嵌套的头库即可获得它们。当然，还有其他方法可以获得这些功能。
我们考虑过切换，但 GCC 4.6 有很多段错误（在使用 --stc++0x 编译的普通 C++03 代码上），我们决定等到支持的编译器将其变为官方 RHEL。

标签： c++ gcc c++11 production-environment

【解决方案1】：

视情况而定。

如果它为我的博客或类似的东西提供动力？肯定的。

如果要为关键服务提供动力？当然不是。

我认为现在对 C++11 的支持还太不成熟，不能称为生产就绪。

您可能会选择 gcc 的一个版本，但事实是，因为随着新问题的发现和解决，后续的草案不断发展，您现在编写的代码很可能会被更高版本拒绝，或者行为可能会发生轻微变化.

因此，我认为这个判断真的取决于你打算做什么。航天飞机由一项古老且经过验证的技术提供动力是有原因的：这是在易于开发和对工具的信心之间进行权衡的问题。

这是你的判断，你比我们更了解你的情况。

【讨论】：

【解决方案2】：

GCC C++ 开发人员仍然认为他们的 C++03 支持达不到标准，因此甚至没有正确设置 __cplusplus 版本（需要引用，我可以查找错误+讨论）。他们将支持标记为实验性的，因为他们在最终草案/标准出现之前就开始实施基础知识。到目前为止（即 GCC 4.6），大多数主要缺陷已被删除，尽管一些细节仍与确切的标准措辞不一致。

如果可能，您还应该使用 Clang 进行测试，恕我直言，在 GCC 缺乏必要执行的大多数地方，它努力并成功地更好地遵守了微不足道的细节。生产用途是个人的。我，我认为每个编译器都有错误，尽管“新东西”中出现错误的可能性在统计上更有可能，但您也可能会遇到一个旧错误，使您完全兼容的代码变得混乱。这就是为什么我建议使用至少两个编译器来防止任何不兼容（或至少尽可能减少它们）。

至于标准库，libstdc++ 大部分是功能性的，但缺少一些大而有用的部分，如<regex>，这是可悲的。如果你觉得幸运的话，你应该能够让 LLVM 的 libc++ 至少在 Linux 和 Mac 上工作，这是一个功能完整的 c++11 库减去 <atomic>），但也是“新来的孩子” ”。

总结一下：运行代码的编译器和标准库越多越好（尽管您应该检查哪些是正确的，哪些是错误的）。这不可避免地会减少您可用的 C++11 功能的数量，尽管如果您使用 GCC/Clang，则只有 lambda、统一初始化程序和 <atomic> 不在您的范围之内。 MSVC 是另一回事...

【讨论】：

__cplusplus 设置错误是一个错误，不是因为缺乏信心。不久前我看到了一张 Bugzilla 票，它基本上证实了在图书馆和平台上滥用该符号（我记得提到过 Sun）已将其锁定为1，至少现在是这样。
@Potatoswatter：请注意__cplusplus，它确实是为 Sun 完成的，并且在最新版本的 gcc（我认为是 4.7+）中已解决。