【问题标题】:gnu c++0x backwards compatibility status - can I just switch it on and go?gnu c++0x 向后兼容状态 - 我可以打开它然后继续吗?
【发布时间】:2011-07-23 10:43:48
【问题描述】:

我有一个相当大的 C++ 代码库(不是自己编写的)。 许多库,有些在语法上不那么重,有些非常重。 其中大量使用了 Boost,一些 Eigen。

我只是喜欢 0x 的一些新功能,并且快速编译/测试告诉我它看起来一切都很好。 This questionand this one 建议有些东西闻起来很有趣。

我现在的状态是:

  • gcc4.4.3
  • libstc++6-4.4
  • boost-1.40
  • 特征 3.0 - beta3

使用std=c++0x 标志。

我知道标准委员会一直在为向后兼容性而苦恼,并忍受着严重的痛苦。 我的问题是,它有效吗?我可以使用所有代码,打开 c++0x 并确定一切不仅可以编译而且可以按预期工作吗?

我不使用高 0x 魔法,只使用 auto 和一些常用的收藏夹,在 GNU C++0x status 上明确标记为“已实现”。

【问题讨论】:

  • 试试热门的新语言,它叫做 C89 :)。适用于一切。你甚至可以在你的 C++ 编译器中使用它!保证升级不会中断。
  • 类似 "sizeof('a')" 的东西在由 C++ 编译器编译时会产生不同的结果,因此即使使用 C89 也无法保证。但是在 C++0x 下是否有任何非人为的 C++98 代码改变行为的例子?

标签: c++ gcc c++11 backwards-compatibility


【解决方案1】:

我当然会推荐使用 GCC 4.5,因为它包含更多错误修复和最新 C++0x 的更可靠实现。

关于您链接的问题:

  1. 这只是一个新平台上的类型定义。不用担心这个,它不会真的破坏任何东西或很难修复。

  2. 1234563语言功能)。

唯一真正检查是否有问题的方法是打开编译器标志,看看是否弹出任何问题。更好的是,打开完整的警告(至少在 GCC 上,MSVC 在这方面存在一些令人烦恼的问题)以检测尽可能多的被破坏的问题。虽然这不是防水的。您可能希望使用不同的编译器(GCC/MSVC/Intel/Clang)来交叉检查兼容性,但在 c++0x 的情况下,您将非常受限于用于检查的编译器的公共子集。目前我广泛使用C++0x,并打算解决最终标准实施时出现的任何问题。

【讨论】:

  • +1 用于打开警告:对编译器的内置机制有一定的信任,以检测某些东西何时闻起来很糟糕。当然,然后测试它是否真的按预期运行。
  • @Matthieu:我没有提到警告标志,但这是个好主意。在 :) 中编辑它
  • 啊!我读了打开编译器标志,并认为您在谈论警告:D
【解决方案2】:

您的问题没有答案,这取决于您的代码。尝试编译,修复编译时问题。编译后,运行您的测试用例,并修复任何需要修复的地方。

如果您没有测试代码,请从那里开始。

【讨论】:

  • 我只是大量图书馆的用户。其中一些非常重的仅标题模板。我无法全部测试它们。在这么大的系统中,我无法检查某处是否有什么东西在潜伏。
  • 这就是一些人所说的“集成测试”——你检查你对这些库的使用是否仍然按预期工作。检查每个库的供应商/项目,看看它们是否可以使用您的 GCC 版本实现的 C++0x。如果连您都无法判断您的软件是否正常运行,您还指望其他人能做到吗?
【解决方案3】:

如果不了解代码库,就无法回答这个问题。特别是,通过 100% 的向后兼容性,您可能会发现通过在同一标准内升级/更改编译器可以发现的相同问题:

如果您的代码不是标准的,如果它使用特定于编译器或版本的功能,如果它有任何未定义行为的实例或依赖于恰好在您当前平台上工作的未指定行为,那么如果可能不是编译(如果你幸运的话)或在运行时表现出不同的行为(如果你不幸运的话)。

【讨论】:

  • +1,可移植性问题的最大原因一直是几乎正确的代码。
猜你喜欢
  • 2013-01-15
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-01-26
  • 1970-01-01
  • 2020-07-26
  • 2010-12-15
  • 2018-01-19
相关资源
最近更新 更多