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