我现在应该使用C ++ 11 lambdas吗？

Question

这就是我的困境：我非常喜欢lambda，并且一直在使用Boost.Fusion和Phoenix。它们非常成熟，可以很好地适应许多编译器。

C ++ 11 lambdas怎么样？它们非常好用，然后更容易使用，然后提升替代品（没有更多的仿函数！）。最近的ICC和GCC编译器支持它们。但是仍然有很多ICC 9.x和GCC 4.1及以下系统，更不用说XL和Sun编译器了。这些编译器是否提供lambda支持？

我倾向于认为也许我应该等待使用C ++ 11功能，以免旧系统拒绝代码。你怎么看？等到较旧的编译器逐渐消失或者只是这样做？

Answer 1

您是否需要能够使用不支持C ++ 11 lambda的编译器编译代码？

如果是这样，那么你就不能使用它们（显然）。否则，没有太多理由不使用它们。

在C ++ 11中对lambda表达式的规范几乎没有变化，因此现在使用它们几乎没有风险。当然会偶尔出现编译器错误，但大多数情况下这些错误很少。

我所知道的唯一与lambda相关的主要特性是支持lambda表达式的多个编译器的最新版本不支持，这是去年三月添加的一个，它允许无捕获的lambda被隐式转换为函数指针。 Visual C ++ 2010和Intel C ++ 11.1不支持（我没有更高版本的英特尔C ++用于测试，对不起）。但是，Visual C ++ 11确实支持隐式转换。

Answer 2

您的目标是多个编译器吗？那就不要。如果您确切地知道您的目标是哪个编译器，并且他们以相同的方式处理语法，那么继续使用新功能！

Answer 3

我对它的看法是，如果你正在处理库代码，你可能应该等待。我的意思是，如果你想将一个库捆绑在一起用于开源分发或者在商业跨平台包中使用，那么你很难控制lambda的编译器支持是什么以及它将如何表现。幸运的是，lambda表达式，无论多么好，主要是关于语法糖。它们不提供比传统仿函数更多的功能，它们只是使它更好，更局部化（当然，我可能错了，我对lambdas的使用知识非常浅）。但是，通常情况下，图书馆意味着隐藏实施的丑陋。如果您需要在不支持lambda的编译器上使这个库可用，那么无论如何都必须提供替代的可移植实现。因此，除非在库中使用lambdas有明显的好处（无论是在效率（编译时间或运行时间）还是在用户体验中（例如，如果您使用lambdas来更轻松或更直观地使用库） ），这可能不值得努力。

但是，对于用户端代码，您可以更轻松地控制软件的目标平台和/或编译器。在这种情况下，如果您预期使用的所有编译器都支持lambdas ..那就疯了！

现在的哲学观点是，人们必须遵守标准。这当然包括制作编译器的人，也包括使用它们的人。当人们开始编写需要lambda支持的好库和/或软件时，想要使用它们的人会开始向编译器制造商抱怨添加支持，这反过来会激励人们使用lambdas ..球也是如此滚动。

最后，通过判断这个新标准引起的嗡嗡声以及等待它发布时的兴奋程度，我认为程序员将很快将这个标准作为“标准”，编译器制造商将拥有跟风以保持活力。

Answer 4

在你自己的代码中，绝对要去吧。事实上，这是一个很好的主意。

对于工作，stackoverflow不是正确的问题。除非你是工作地点的决策者，否则你的编译器会知道你在说什么。在这种情况下，我鼓励你做得很棒。