我现在应该使用 C++11 lambda 吗？
这是我的困境：我真的很喜欢 lambda，并且经常使用 Boost.Fusion 和 Phoenix。它们非常成熟，并且在许多编译器上都能很好地运行。
C++11 lambda 怎么样？它们真的很好，而且比 boost 替代品更容易使用（不再有函子！）。最近的 ICC 和 GCC 编译器支持它们。但仍然有很多 ICC 9.x 和 GCC 4.1 及以下系统，更不用说 XL 和 Sun 编译器了。这些编译器提供 lambda 支持吗？
我倾向于认为也许我应该等待使用 C++11 功能，以免旧系统拒绝代码。你怎么认为？等到旧的编译器消失还是干脆这样做？
Here is my dilemma: I really like lambda and have been using Boost.Fusion and Phoenix a lot lot. They are pretty mature and play nicely across many compilers.
What about the C++11 lambdas? They are really nice and much more easier to use then boost alternatives (no more functors!). Recent ICC and GCC compilers support them. But there are still lots of ICC 9.x and GCC 4.1 and below systems not to mention XL and Sun compilers. Do those compilers offer lambda support?
I tend to think that perhaps I should wait to use C++11 features lest older systems reject the code. What do you think? Wait till older compilers fade away or just do it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您是否需要能够使用不支持 C++11 lambda 的编译器来编译代码？
如果是这样，那么你就不能使用它们（显然）。否则，真的没有太多理由不使用它们。
C++11 中 lambda 表达式的规范几乎没有变化，因此现在使用它们的风险很小。当然，偶尔会出现编译器错误，但大多数情况下这些错误很少而且相距甚远。
据我所知，支持 lambda 表达式的多个编译器的最新版本不支持的唯一与 lambda 相关的主要功能是去年 3 月添加的功能，该功能允许将无捕获 lambda 隐式转换为函数指针。 Visual C++ 2010 和 Intel C++ 11.1 不支持这一点（抱歉，我没有用于测试的更高版本的 Intel C++）。但是，Visual C++ 11 确实支持隐式转换。
Do you need to be able to compile your code using a compiler that doesn't support C++11 lambdas?
If so, then you can't use them (obviously). Otherwise, there's really not much reason not to use them.
There have been few changes to the specification of lambda expressions in C++11, so there is little risk to using them now. Certainly there will be occasional compiler bugs, but for the most part those are few and far between.
The only major lambda-related feature of which I am aware that is not supported by the latest versions of multiple compilers that support lambda expressions is one that was added last March, which allows captureless lambdas to be implicitly converted to function pointers. Visual C++ 2010 and Intel C++ 11.1 don't support that (I don't have a later version of Intel C++ with which to test, sorry). Visual C++ 11 does support the implicit conversion, however.
您的目标是多个编译器吗？那么，不。如果您确切地知道您要使用哪个编译器，并且它们以相同的方式处理语法，那么请继续使用新功能！
Are you aiming at multiple compilers? Then, no. If you know precisely which compiler(s) you're aiming for, and they handle the syntax the same way, then go ahead and use the new features!
我的观点是，如果您正在处理库代码，您可能应该等待。我的意思是，如果您想将一个库捆绑在一起用于开源分发或在商业跨平台包中使用，那么您几乎无法控制对 lambda 的哪些编译器支持可用以及其行为方式。幸运的是，无论 lambda 表达式多么好，它主要都是关于语法糖的。它们并没有提供比传统函子更多的功能，它们只是让它变得更好、更本地化（当然，我对此可能是错的，我对 lambda 用法的了解相当肤浅）。但是，通常，库的目的是隐藏实现的丑陋之处。如果您需要让这个库在不支持 lambda 的编译器上可用，您无论如何都必须提供替代的、可移植的实现。因此，除非在您的库中使用 lambda 可以带来明显的收益（无论是效率（编译时间或运行时间）还是用户体验（例如，如果您使用 lambda 来使库的使用更容易、更清晰或更直观） ），这可能不值得付出努力。
但是，对于用户端代码，您可以更轻松地控制软件的目标平台和/或编译器。在这种情况下，如果您期望使用的所有编译器都支持 lambda...那么就发疯吧！
现在的哲学观点是，标准是供人们遵守的。这当然包括制作编译器的人，也包括使用编译器的人。当人们开始编写需要 lambda 支持的优秀库和/或软件时，想要使用它们的人会开始向编译器制造商抱怨添加支持，这反过来又会激励人们使用 lambda。开始滚动。
最后，通过判断这个新标准引起的轰动程度以及等待其发布时所产生的兴奋程度，我认为程序员将很快使该标准成为“标准”，而编译器制造商将不得不效仿为了活下去。
My perspective on it is that if you are working on library code you probably should wait. I mean, if you want to bundle a library together either for open-source distribution or use in a commercial cross-platform package, then you can hardly control what compiler support for lambdas will be available and how it will behave. Luckily, lambda expressions, however nice, are mostly about syntactic sugar. They don't offer more functionality than traditional functors, they simply make it nicer and more localized (of course, I may be wrong about this, my knowledge of the uses of lambdas is pretty shallow). But, typically, a library is meant to hide away the ugliness of the implementation. And if you are going to need to make this library usable on compilers that don't support lambdas, you will have to provide the alternative, portable implementations anyways. So, unless there is a clear gain in using lambdas in your library (either in efficiency (compilation time or running time) or in user experience (e.g. if you are using lambdas to make the use of your library easier or clearer or more intuitive)), it is probably not worth the effort.
However, for user-side code, you can more easily control the target platforms and/or compilers for your software. In that case, if all the compilers you are anticipating to use support lambdas.. then go nuts!
Now the philosophical point, standards are there for people to conform to them. That includes of course the people making the compilers, but also the people using them. When people start writing nice libraries and/or software that requires lambda support, people who want to use them will start to complain to the compiler makers to add the support, which in turn will motivate people to use lambdas.. and so does the ball get rolling.
Finally, by judging the amount of buzz that this new standard is raising and the excitement that has been building while awaiting its release, I think programmers will be quick to make this standard "the standard", and compiler-makers will have to follow suit to stay alive.
在您自己的代码中，绝对可以这样做。事实上，这是个好主意。
对于工作，stackoverflow 不是询问的合适地方。除非您是工作场所的决策者，并且您的编译器知道您在说什么。在这种情况下，我鼓励你变得很棒。
In your own code, absolutely, go for it. It's an excellent idea, in fact.
For work, stackoverflow isn't the right place to ask. Unless you're the decision maker at your place of work, and your compiler knows what you're talking about. In which case I encourage you to be awesome.