使用或不使用 C++0x 功能
可能的重复：
您今天使用 C++0x 的情况如何？
我建议在我们这样做之后，我们开始利用一些已经提供的 C++0x 功能，例如 auto.我的同事建议反对这一点，建议等到“C++0x 真正成为标准”。我不得不不同意，但我可以从他的措辞中看到吸引力。尽管如此，我还是忍不住认为这种反驳更多地是出于对学习 C++0x 的恐惧和恐惧，而不是对标准化的真正关注。
鉴于系统的新状态，我希望我们能够利用可用的新技术。例如，仅仅使用 auto 就可以让我们的日常生活变得更轻松（例如，只需编写基于迭代器的 for 循环，直到出现基于范围的循环）。
我这样想有错吗？我并不是建议我们从根本上改变我们刚刚萌芽的代码库，而是开始在方便的地方使用 C++0x 功能。我们知道我们正在使用什么编译器，并且没有立即移植的计划（如果我们移植代码库，那么到那时编译器肯定也将可用于目标平台）。否则，在我看来，就像在 1997 年避免使用 iostreams 只是因为 ISO C++ 标准尚未发布，尽管所有编译器都已经以可移植的方式提供了它们。
如果你们都同意，你能给我提供一些可以用来加强我的立场的论据吗？如果没有，我能否获得有关“直到 C++0x 成为标准”想法的更多详细信息？顺便说一句，有人知道那是什么时候吗？
Possible Duplicate:
How are you using C++0x today?
I'm working with a team on a fairly new system. We're talking about migrating to MSVC 2010 and we've already migrated to GCC 4.5. These are the only compilers we're using and we have no plans to port our code to different compilers any time soon.
I suggested that after we do it, we start taking advantage of some of the C++0x features already provided like auto. My co-worker suggested against this, proposing to wait "until C++0x actually becomes standard." I have to disagree, but I can see the appeal in the way he worded it. Nevertheless, I can't help but think that this counter-argument comes more out of fear and trepidation of learning C++0x than a genuine concern for standardization.
Given the new state of the system, I want for us to take advantage of the new technology available. Just auto, for instance, would make our daily lives easier (just writing iterator-based for loops until range-based loops come along, e.g.).
Am I wrong to think this? It is not as though I'm proposing we radically change our budding codebase, but just start making use of C++0x features where convenient. We know what compilers we're using and have no immediate plans to port (if we ever port the code base, by then surely compilers will be available with C++0x features as well for the target platform). Otherwise it seems to me like avoiding the use of iostreams in 1997 just because the ISO C++ standard was not published yet in spite of the fact that all compilers already provided them in a portable fashion.
If you all agree, could you provide me arguments I could use to strengthen my position? If not, could I get a bit more details on this "until the C++0x is standard" idea? BTW, anyone know when that's going to be?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我会根据每个功能做出决定。
请记住，该标准确实即将完成。剩下的就是投票、修复错误和更多投票。
因此，像
auto这样的简单功能不会消失，也不会改变其语义。那么为什么不使用它呢。Lambda 足够复杂，以至于它们的措辞可能会发生变化，并且一些极端情况下的语义也会得到一些修复，但总的来说，它们的行为方式将与今天相同（尽管 VS2010 在范围方面存在一些错误）对于捕获的变量，MS 已声明它们是错误，因此可能会在主要产品版本之外修复）。
如果您想安全起见，请远离 lambda。否则，请在方便的地方使用它们，但要避免超级棘手的情况，或者准备好在标准最终确定时检查 lambda 的使用情况。
大多数功能都可以这样分类，它们要么非常简单和稳定，以至于它们在 GCC/MSVC 中的实现正是它们在最终标准中的工作方式，要么它们足够棘手，可能会修复一些错误已应用，因此它们现在可以使用，但在某些边界情况下您可能会遇到一些粗糙的问题。
仅仅因为 C++0x 功能尚未正式化就避免它们，这听起来确实很愚蠢。避免使用您不相信其完整、无错误且稳定的功能，而使用其余功能。
I'd make the decision on a per-feature basis.
Remember that the standard is really close to completion. All that is left is voting, bugfixing and more voting.
So a simple feature like
autois not going to go away, or have its semantics changed. So why not use it.Lambdas are complex enough that they might have their wording changed and the semantics in a few corner cases fixed up a bit, but on the whole, they're going to behave the way they do today (although VS2010 has a few bugs about the scope of captured variables, MS has stated that they are bugs, and as such may be fixed outside of a major product release).
If you want to play it safe, stay away from lambdas. Otherwise, use them where they're convenient, but avoid the super tricky cases, or just be ready to inspect your lambda usage when the standard is finalized.
Most features can be categorized like this, they're either so simple and stable that their implementation in GCC/MSVC are exactly how they're going to work in the final standard, or they're tricky enough that they might get a few bugfixes applied, and so they can be used today, but you run the risk of running into a few rough edges in certain border cases.
It does sound silly to avoid C++0x feature solely because they're not formalized yet. Avoid the features that you don't trust to be complete, bug-free and stable, but use the rest.
使用 C++0x 的理论而非实践缺点：
使用 C++0x 的实用优势：
这是理论上正确与实际之间的争论。如果您的团队有意使用此代码实际执行某些操作，那么实际操作应该比理论操作重要十倍。
Theoretical but not practical disadvantages of using C++0x:
Practical advantages of using C++0x:
It's a debate between what's theoretically right, and what's practical. If your team has any intent of actually doing something with this code, the practical should outweigh the theoretical tenfold.
您现在（大部分）不需要担心的一件事是添加或删除的功能，因为工作草案在三月份就达到了“最终委员会草案”(FCD)。功能方面应该被冻结，标准委员会将不再接受任何关于 C++0x 的提案。
缺点是它仍然是草案，尚未最终确定，标准委员会正处于修正和调整阶段，然后最终确定并发布 ISO 标准（预计于 2011 年 3 月发布）。这可能意味着细微的语法或语义/行为更改，一旦您使用比编写代码时使用的编译器更符合标准的编译器进行编译，这些更改可能会使您的代码无法编译或无法正常工作。
您可能需要等待一段时间，像 VC++10 这样的编译器才能进行任何更正/调整的更新。
One thing you don't need to (mostly) worry about now is features being added or taken away because the working draft reached "Final Committee Draft" (FCD) back in march. Feature-wise should be frozen, standards committee will not accept any-more proposals for C++0x.
Downside is it's still a draft and not finalized yet, the standards committee are in the phase of making corrections and adjustments before finalizing and publish the ISO standard (expected release to be march 2011). That could mean minor syntactic or semantic/behaviour changes which could make your code not compilable or not work correctly once you compile with a compiler that is more standard compliant than the one you're using at the time you wrote the code.
You'll probably have to wait sometime for compilers like VC++10 to get update with any corrections/adjustments made.
我们遇到了完全相同的问题，所以我们妥协了。我们采用了 C++ 0x TR1 版本，然后只采用了我们知道想要使用的部分。听起来工作量很大，但到目前为止进展顺利。我们使用正则表达式库、元组和其他一些库。一旦标准获得批准，我们将迁移到完整的 C++ 0x。这显然不是最好的解决方案，但对我们来说效果很好。
We had the exact same problem so we compromised. We took the C++ 0x TR1 release and then only took the portions that we knew we wanted to use. Sounds like a lot of work, but so far it's worked out well. We're using the regex libraries, tuples, and a couple of others. Once the standard is ratified, then we'll migrate to the full C++ 0x. This obviously isn't the best solution but it was one that has worked well for us.
如果您打算在不久的将来使您的系统开源，那么就可以考虑不使用太多前沿功能。运行 Debian 或 Red Hat 的生产系统不一定安装先进的编译器。
你说
但平台存在编译器并不总是意味着它已安装/使用/需要，尤其是在生产系统。
另一方面，如果您打算自己完成所有编译工作，那么这不是问题。
If you intend to make your system open source within a not-too-far future, then that's an argument for not using too many bleeding-edge features. A production system running Debian or Red Hat won't necessarily have a bleeding-edge compiler installed.
You said
but that a compiler exists for a platform doesn't always mean that it's installed/used/wanted, especially on production systems.
If, on the other hand, you intend to do all the compiling yourself, this is not an issue.