Lambda Functions and Closures officially in C++0x
Saturday, 29 March 2008
Herb Sutter just posted about the most recent ISO C++ Standards Meeting. The most exciting news is that lambda functions and closures have been officially voted into C++0x! This is really going to make taking advantage of the Standard Algorithms much more straightforward.
Here's a little taste from Herb's post:
Yes, you can already achieve the same thing today, with a standard binary predicate and a helper, thusly:
find_if(w.begin(), w.end(), bind2nd(greater<int>(), 100));
but it isn't nearly as easy on the eye, is it?
Lambda functions will also make it a lot easier in situations where now you'd be forced to use a custom predicate; previously you'd have to: create a functor; remember to make it inherit from std::unary_function or std::binary_function for completeness; stick it in an anonymous namespace (optional but recommended; and finally, use it in your invocation of one of the standard algorithms. That works, but if you're coding a for_each, because you're trying to be good and not write a loop on an STL container by hand, then having the interesting part of the loop in a functor makes the code much harder to follow: instead of it being right there in the loop, it has to be somewhere else, breaking up the flow of the logic in the poor reviewer's head.
Here's a little taste from Herb's post:
In C++0x, you can just write:
// Calling find_if using a lambda, in C++0x:
find_if( w.begin(), w.end(),
[]( const Widget& w ) -> bool { w.Weight() > 100; } );
Yes, you can already achieve the same thing today, with a standard binary predicate and a helper, thusly:
find_if(w.begin(), w.end(), bind2nd(greater<int>(), 100));
but it isn't nearly as easy on the eye, is it?
Lambda functions will also make it a lot easier in situations where now you'd be forced to use a custom predicate; previously you'd have to: create a functor; remember to make it inherit from std::unary_function or std::binary_function for completeness; stick it in an anonymous namespace (optional but recommended; and finally, use it in your invocation of one of the standard algorithms. That works, but if you're coding a for_each, because you're trying to be good and not write a loop on an STL container by hand, then having the interesting part of the loop in a functor makes the code much harder to follow: instead of it being right there in the loop, it has to be somewhere else, breaking up the flow of the logic in the poor reviewer's head.
More C++0x fun
Tuesday, 11 September 2007
For more C++0x fun, check out Herb Sutter's trip report for the July 2007 ISO C++ Standard meeting.
OnSoftware Video Podcast
Tuesday, 11 September 2007
OnSoftware is putting out some pretty neat video podcasts right now. As a (predominately) C++ guy, I found the ones with Bjarne Stroustrup, Herb Sutter and Scott Meyers to be particularly interesting.
They're making me eager for C++0x to get here! I realize it's going to be a while though: to my knowledge, Microsoft still haven't said when Visual C++ will have TR1 support, never mind C++0x. I can live with getting my
shared_ptr
fix from the the Boost libraries for now, but having shared pointers fully and officially in the language, along with things like lambda functions, will certainly make life easier.Note that you can get TR1 now from Dinkumware, and they'll likely be first to put out proper C++0x support once it's ratified (fingers crossed for 2009). P.J. Plauger and Pete Becker are very nice to deal. Indeed, we used Dinkumware on Windows CE 4.2 so that we could make use of streams. Unfortunately for our application, it's tough to justify the overhead of an alternate library, and we had problems on other people's devices that exported C++ APIs in their SDKs (they would export a function that returned a Microsoft
std::wstring
for example, which isn't binary compatible with a Dinkumware std::wstring
so we'd end up wrapping their SDK in C: very ugly).