使用或不使用C++ 0x特性[复制]

记住标准是 真正地

所以一个简单的功能 auto 不会消失,也不会改变它的语义。那为什么不用呢。

如果你想安全起见,离兰巴斯远点。否则,在方便的地方使用它们,但要避免那些非常棘手的情况,或者在标准最终确定后随时检查lambda的使用情况。

大多数特性都可以这样分类,它们要么非常简单和稳定,以至于在GCC/MSVC中的实现正是它们在最终标准中的工作方式,要么非常复杂,可能会应用一些错误修复,因此它们可以

仅仅因为它们还没有正式化,避免C++ +0x特性听起来很傻。避免使用那些你不信任的功能,它们是完整的、无bug的和稳定的,但要使用其余的。

理论而非实践 使用C++ 0x的缺点:

• 不遵守任何公布的标准。

实用的

• 让你的日常生活更轻松,因此更有效率。

现在你不必(主要)担心的一件事是,由于达到了工作草案,功能被添加或删除。” “(FCD)早在三月份。功能化应该被冻结,标准委员会将不再接受C++的更多建议。

缺点是它仍然是一个草案,尚未定稿,标准委员会正在进行修正和调整,然后定稿并公布ISO标准(预计2011年3月发布)。这可能意味着轻微的语法或语义/行为改变,一旦使用比编写代码时使用的编译器更符合标准的编译器进行编译,可能会导致代码无法编译或无法正常工作。

您可能需要等待一段时间,等待VC++10之类的编译器更新所做的任何更正/调整。

我们有完全相同的问题,所以我们妥协了。我们采用C++ 0xTr1版本,然后只使用了我们想知道的部分。听起来工作量很大,但到目前为止效果还不错。我们正在使用正则表达式库、元组和其他一些库。一旦标准被批准,我们将迁移到完整的C++ 0x。这显然不是最好的解决方案,但对我们来说效果很好。

如果您打算在不久的将来使您的系统开源,那么这就是不使用太多前沿特性的理由。运行Debian或Red Hat的生产系统不一定要安装最先进的编译器。

如果我们曾经移植过代码库,那么编译器肯定会对目标平台也有C++ 0x特性。

但是,存在一个平台的编译器并不总是意味着它已经安装/使用/需要,特别是在生产系统上。