On Thu, 26 Jan 2012, Philipp Moeller wrote:
Jeremiah Willcock
writes: On Wed, 25 Jan 2012, Eric Niebler wrote:
On 1/25/2012 6:42 PM, Jeremiah Willcock wrote:
At least on GCC 4.6 in C++0x (C++11) mode, BOOST_RESULT_OF_USE_DECLTYPE is not set by default, preventing classes such as boost::transform_iterator from working on built-in lambda expressions. Is there a reason that the use of decltype is not on by default for compilers that support it, perhaps with a flag to force emulation mode (like Boost.Move supports)?
It's not the default because when we made it the default, all heck broke loose. Partly it was because of buggy libraries that returned a different type from operator() than their nested result<> template declared. Partly, it was due to a bug in the specification of decltype that was only resolved in closing minutes with the adoption of N3276[*]. And partly it is because of continuing non-compliance of compilers that don't property implement N3276.
Would it be possible to use decltype to at least handle C++11 lambdas (which are the one case where normal result_of is broken)? Is there a type trait to detect those?
-- Jeremiah Willcock
As a template argument a lambda is indistinguishable from any other functor (it may also have a conversion to a function pointer), so I don't think this is possible.
You can try to turn the feature on by defining the macro yourself (with Boost.Config) and check if anything breaks. Your users however will be in for nice surprise if they include your headers and get a C++11 result_of which breaks boost libraries that they might include themselves.
So far I'm using a -D on the compile line to turn it on; luckily, the code I'm using this in is an application, so I don't need to worry about people including these files yet. -- Jeremiah Willcock