Should I use C++11 lambdas now?

Question

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?

Answer 1

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.

Answer 2

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!

Answer 3

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.