1

I want to compute the element-wise difference of two vectors using Boost.Range and C++1y lambdas with init-capture. The simpler case of subtracting a fixed (i.e. the first) element of one vector works. However, when I try to compute the "vectorized difference" by increasing the iterator over the second range (and making the lambda mutable), I get a compiler error. Sample code (note that I didn't use generalized lambdas so that both g++ 4.8 and Clang SVN can parse this code):

#include <iostream>
#include <iterator>
#include <vector>
#include <boost/range/algorithm.hpp>
#include <boost/range/adaptors.hpp>

template<class R>
auto delta_beg(R const& rng1, R const& rng2)
{
    using Elem = typename R::value_type;
    return rng1 | boost::adaptors::transformed(
        [first2 = begin(rng2)](Elem const& e) {
        return e - *first2;
    });
}

template<class R>
auto delta_rng(R const& rng1, R const& rng2)
{
    using Elem = typename R::value_type;
    return rng1 | boost::adaptors::transformed(
        [first2 = begin(rng2)](Elem const& e) mutable {
        return e - *first2++;
    });
}

int main()
{
    auto r1 = std::vector<int>{ 8, 10, 12, 15 };
    auto r2 = std::vector<int>{ 1,  2,  9, 13 };

    // prints 7, 9, 11, 14
    boost::copy(delta_beg(r1, r2), std::ostream_iterator<int>(std::cout, ",")); std::cout << "\n";

    // ERROR, should print 7, 8, 3, 2
    boost::copy(delta_rng(r1, r2), std::ostream_iterator<int>(std::cout, ",")); std::cout << "\n";
}

Live Example. Here both g++ and Clang complain about

no type named 'type' in 'boost::mpl::eval_if, boost::result_of]::__lambda1(const int&)>, boost::mpl::identity >::f_ {aka struct boost::result_of]::__lambda1(const int&)>}' typedef typename f_::type type;

Question: what is going on?

TemplateRex
  • 69,038
  • 19
  • 164
  • 304

1 Answers1

2

It's just that closure-types don't have nested typedefs that boost::mpl apparently requires. It works if you convert the lambda expression to std::function:

#include <iostream>
#include <iterator>
#include <vector>
#include <boost/range/algorithm.hpp>
#include <boost/range/adaptors.hpp>

template<class R>
auto delta_beg(R const& rng1, R const& rng2)
{
    using Elem = typename R::value_type;
    std::function<Elem(Elem const&)> f = 
        [first2 = begin(rng2)](Elem const& e) { return e - *first2; };
    return rng1 | boost::adaptors::transformed(f);
}

template<class R>
auto delta_rng(R const& rng1, R const& rng2)
{
    using Elem = typename R::value_type;
    std::function<Elem(Elem const&)> f = 
        [first2 = begin(rng2)](Elem const& e) mutable { return e - *first2++; };
    return rng1 | boost::adaptors::transformed(f);
}

int main()
{
    auto r1 = std::vector<int>{ 8, 10, 12, 15 };
    auto r2 = std::vector<int>{ 1,  2,  9, 13 };

    // prints 7, 9, 11, 14
    boost::copy(delta_beg(r1, r2), std::ostream_iterator<int>(std::cout, ",")); std::cout << "\n";

    // ERROR, should print 7, 8, 3, 2
    boost::copy(delta_rng(r1, r2), std::ostream_iterator<int>(std::cout, ",")); std::cout << "\n";
}

Live demo.

jrok
  • 54,456
  • 9
  • 109
  • 141
  • ah great! but the `delta_beg` did work with a lambda, why is it that mutable lambdas are probed for a nested `type`? – TemplateRex Feb 12 '14 at 10:23
  • Hm, interesting, I didn't notice that. I don't know the answer to that, I'm afraid. – jrok Feb 12 '14 at 10:28
  • in any case, I would rather use a handwritten function object than `std::function` here to sidestep all the virtual overhead or the worries about it. – TemplateRex Feb 12 '14 at 10:51
  • Yeah, I understand that. Well, I'm stuck finding the issue here. I thought the culprit might be `boost::result_of` (which didn't play well with lambdas in the past), but testing it shows that it works with both mutable and non-mutable lambdas. :/ – jrok Feb 12 '14 at 10:54
  • 1
    @TemplateRex Ok, [here](http://coliru.stacked-crooked.com/a/c33017caf1df49ae) is an SSCCE - if you remove capture-init, it compiles fine. – jrok Feb 12 '14 at 11:20
  • 1
    jrok something is terribly broken about lambda-capture and Boost.Range. [here](http://coliru.stacked-crooked.com/a/f8983b17bd289a21) is another SSCE where regular capture-by-reference using Boost.Range gives different result than using `std::transform` – TemplateRex Feb 12 '14 at 12:00
  • It seems compiler's bug. I think need bug report to Clang and GCC. – Akira Takahashi Feb 13 '14 at 05:46
  • @AkiraTakahashi can you explain the error? What is the `mpl::eval_if` looking for in the lambda? – TemplateRex Feb 13 '14 at 05:57
  • 1
    Ah, sorry. This is Boost.Iterator's issue. `boost::transform_iterator` use `const F`'s result_type. https://github.com/boostorg/iterator/blob/master/include/boost/iterator/transform_iterator.hpp So, `boost::adaptors::transformed` don't accept mutable function object. Minimal code is here: http://melpon.org/wandbox/permlink/xjQqudJcBK8LWi72 – Akira Takahashi Feb 13 '14 at 15:32