Boost logo

Boost :

Subject: Re: [boost] [result_of] Allow result_of to work with C++11 lambdas
From: Eric Niebler (eniebler_at_[hidden])
Date: 2013-04-09 02:05:27

On 13-04-08 10:50 PM, Nathan Crookston wrote:
> Hi all,
> Using C++11 lambda functions with several boost components. For example,
> the following code snippet will not work with VC10, nor with g++ up to 4.8:
> #include <boost/assign.hpp>
> #include <boost/range/adaptors.hpp>
> #include <boost/range/algorithm.hpp>
> #include <iostream>
> int main()
> {
> std::vector<int> v;
> for(int i = 0; i < 10; ++i) v.push_back(i);
> boost::for_each(v | boost::adaptors::transformed([](int i) { return i *
> 2; }),
> [](int i) { std::cout << i << std::endl; });
> }
> g++4.5 gives around 34k of error messages, while VC10 has a mere 22k.
> The root of these problems is that lambda functions don't conform to the
> tr1::result_of protocol -- there is no nested result_type member, nor
> nested result struct. The standard doesn't mandate this case since
> decltype may be used to deduce the return type on C++11-conforming
> compilers.
> boost::result_of disables the use of decltype on many compilers in favor of
> tr1-style deduction due to weaknesses in the implementation of decltype.
> While it is important to use tr1-protocol result_of to allow code involving
> incomplete types to compile, it would be very convenient to fall back to a
> decltype approach when it's detected that the tr1 protocol is not being
> followed.
> Jeff Hellrung suggested[1] a fallback to decltype *only* for compilers
> which had nonconforming decltype operators. Thus the only behavioral
> change would be that some code which before would produce an error would
> now compile and run correctly.
> A ticket[1] with a patch (including tests and docs) was created. Daniel
> Walker suggested further discussion on the list, which this attempts to
> provoke. I think this would be a nice improvement for a set of often-used
> compilers -- the list of boost-users questions whose problems could be
> addressed by this patch is extensive (and can be provided, if desired).
> Thanks,
> Nate
> [1]
> [2]

For the record, I'm in favor of this. Daniel Walker is the maintainer of
result_of, but I've occasionally made changes myself. I haven't looked
at the patch in question, but it's been on my todo list for a long time.
My todo list has gotten pretty long, so if you or Daniel beat me to it,

Eric Niebler

Boost list run by bdawes at, gregod at, cpdaniel at, john at