Boost logo

Boost :

Subject: Re: [boost] [result_of] Allow result_of to work with C++11 lambdas
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2013-04-09 20:22:09

On Apr 9, 2013, at 2:05 AM, Eric Niebler <eniebler_at_[hidden]> wrote:

> 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,
> bonus.

I like the idea as well. I could devote some time to this and look at the patch again if there is any interest.

- Daniel

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