我正在与一个相当新系统的团队合作。我们正在谈论迁移到MSVC 2010，我们已经迁移到GCC 4.5。这些是我们使用的唯一编译器，我们没有计划很快将代码移植到不同的编译器。
我建议在我们这样做之后，我们开始利用已经提供的一些C ++ 0x功能，比如auto。我的同事暗示反对这一点，建议等待“直到C ++ 0x实际上成为标准。”我不同意，但我可以用他的措辞来看待它的吸引力。尽管如此，我不禁认为这种反驳更多的是出于对学习C ++ 0x的恐惧和恐惧而不是对标准化的真正关注。
鉴于系统的新状态，我希望我们能够利用现有的新技术。例如，只需自动就可以让我们的日常生活更轻松（只需编写基于迭代器的循环，直到基于范围的循环出现，例如。）。
我认为这是错的吗？我并不是在提议我们从根本上改变我们萌芽的代码库，而只是在方便的时候开始使用C ++ 0x功能。我们知道我们正在使用哪些编译器并且没有立即移植的计划（如果我们曾经移植过代码库，那么当然编译器将具有C ++ 0x功能以及目标平台）。否则，我似乎在1997年避免使用iostreams只是因为ISO C ++标准尚未发布，尽管所有编译器都已经以便携方式提供它们。
如果大家都同意，你能否提供我可以用来巩固我的立场的论据？如果没有，我可以获得更多关于“直到C ++ 0x是标准”的想法吗？顺便说一句，谁知道什么时候会发生？
答案 0 :(得分：10)
我会根据每个功能做出决定。
请记住，标准确实接近完成。剩下的就是投票，错误修正和更多投票。
因此像auto这样的简单功能不会消失，或者其语义发生变化。那么为什么不使用呢。
Lambdas足够复杂，他们可能会改变他们的措辞，并且在一些极端情况下的语义有点固定，但总的来说，他们将按照他们今天的方式行事（虽然VS2010有一些bug关于捕获变量的范围，MS已声明它们是错误，因此可能在主要产品发布之外修复。）
如果你想安全玩耍，请远离lambdas。否则，在方便的地方使用它们，但避免使用超级棘手的情况，或者在标准最终确定时准备检查lambda的使用情况。
大多数功能都可以这样分类，它们要么是如此简单又稳定，以至于它们在GCC / MSVC中的实现正是它们在最终标准中的工作方式，或者它们非常棘手以至于它们可能会得到应用了一些错误修正，因此今天可以使用 ，但是在某些边界情况下你可能会遇到一些粗糙的边缘。
完全避免使用C ++ 0x功能确实很愚蠢，因为它们还没有正式化。避免使用您不信任的功能，使其完整，无错误且稳定，但请使用其余功能。
答案 1 :(得分：8)
理论但不实用使用C ++ 0x的缺点：
实用使用C ++ 0x的优势：
这是在理论上正确和什么是实际的辩论。如果你的团队有任何意图用这个代码实际做某事，那么实际应该超过理论上的十倍。
答案 2 :(得分：7)
你现在不需要（大部分）担心的一件事就是添加或删除功能，因为工作草案在3月份达到“最终委员会草案”（FCD）。功能方面应该被冻结，标准委员会不会接受任何更多的C ++ 0x提案。
下行仍然是草案，尚未最终确定，标准委员会正在进行更正和调整，最终确定并公布ISO标准（预计将于2011年3月发布）。这可能意味着轻微的语法或语义/行为更改，一旦您使用比您编写代码时使用的编译器更符合标准的编译器进行编译，可能会使您的代码无法编译或无法正常工作。
你可能需要等一段时间才能让VC ++ 10等编译器通过任何更正/调整来获得更新。
答案 3 :(得分：3)
我们遇到了完全相同的问题，所以我们妥协了。我们采用了C ++ 0x TR1版本，然后只获取了我们想要使用的部分。听起来很多工作，但到目前为止它的效果很好。我们正在使用正则表达式库，元组和其他几个。一旦标准被批准，那么我们将迁移到完整的C ++ 0x。这显然不是最好的解决方案，但它对我们来说效果很好。
答案 4 :(得分：1)
如果您打算在不太远的将来使您的系统开源，那么这就是不使用太多前沿功能的论据。运行Debian或Red Hat的生产系统不一定要安装前沿的编译器。
你说
如果我们移植代码库，那么肯定编译器将具有C ++ 0x功能以及目标平台
但是平台的编译器并不总是意味着它已经安装/使用/想要，特别是在生产系统上。
另一方面，如果您打算自己编译，这不是问题。