Lambda and Tuple question

[Jerzie.Klenchier]

Hi all,

I'm having some difficulty in getting the following piece of code to
compile:

#include <iostream>
#include <deque>
#include <algorithm>
#include <boost/tuple/tuple.hpp>
#include <boost/lambda/lambda.hpp>

int main(void)
{
typedef boost::tuples::tuple<unsigned int, double> my_tuple_type;
std::deque<my_tuple_type> my_list;

std::sort(my_list.begin(),my_list.end(),
(boost::lambda::_1).get<0>() <
(boost::lambda::_2).get<0>());

return 0;

}

my understanding of the lambda place-holders was that they represent
the value_type of the iterators in the above example. A simpler
example as below seems to work, just wondering why the above doesn't.

{
std::vector<int> v_list;
std::sort(v_list.begin(),v_list.end(),
boost::lambda::_1 < boost::lambda::_2);

}

Jerzie

 

[Kai-Uwe Bux]

Hi all,

I'm having some difficulty in getting the following piece of code to
compile:

#include <iostream>
#include <deque>
#include <algorithm>
#include <boost/tuple/tuple.hpp>
#include <boost/lambda/lambda.hpp>

int main(void)
{
typedef boost::tuples::tuple<unsigned int, double> my_tuple_type;
std::deque<my_tuple_type> my_list;

std::sort(my_list.begin(),my_list.end(),
(boost::lambda::_1).get<0>() <
(boost::lambda::_2).get<0>());

return 0;

}

my understanding of the lambda place-holders was that they represent
the value_type of the iterators in the above example. A simpler
example as below seems to work, just wondering why the above doesn't.

We cannot overload the dot-operator (what a shame!). Therefore, the magic
functor _1 cannot forward member functions.

You can try to use bind to make it work. So, instead of _1.get<0>, you would
have a monstrosity like:

{
std::vector<int> v_list;
std::sort(v_list.begin(),v_list.end(),
boost::lambda::_1 < boost::lambda::_2);

}

That works just fine because lambda does not run into limitations of the C++
core language (another thing that lambda cannot support elegantly is
some_vector[_1] since operator[] has to be a member function).


Best

Kai-Uwe Bux

 

[Marcel Müller]

We cannot overload the dot-operator (what a shame!). Therefore, the magic
functor _1 cannot forward member functions.

You can try to use bind to make it work. So, instead of _1.get<0>, you would
have a monstrosity like:

bind( &whatever_type::get<0>, _1 )

(or worse: I did not try it.)

What about the old trick

(*&_1).get<0>()

Normally this should work too. Of course, it implies that the operator&
of the object behind _1 is not overloaded in some magic way.

(I did not test it, since I have no boost::lambda currently running here.)



Marcel

 

[brian tyler]

The boost lambda library is wonderful in theory, but IMO a nightmare
in practice.

It's a seriously clever piece of software, and the authors should take
full credit for the ingenuity of it, but the time scale for using it
goes something like:

* for loop with iterators
* algorithm library with custom function object (or functional
library) ~ 2-3 times longer to program, similar performance as for
loop
* Boost Lambda library ~ a good 10 times longer than a for loop (if
ever) to program, significantly worse performance

I know it looks really nifty to have a bit of lambda in the code, but
I'm just curious to know if anyone has a compelling (non-academic)
reason to wrestle with the beast that is the BLL?

Brian

 

[Pascal J. Bourguignon]

The boost lambda library is wonderful in theory, but IMO a nightmare
in practice.

It's a seriously clever piece of software, and the authors should take
full credit for the ingenuity of it, but the time scale for using it
goes something like:

* for loop with iterators
* algorithm library with custom function object (or functional
library) ~ 2-3 times longer to program, similar performance as for
loop
* Boost Lambda library ~ a good 10 times longer than a for loop (if
ever) to program, significantly worse performance

I know it looks really nifty to have a bit of lambda in the code, but
I'm just curious to know if anyone has a compelling (non-academic)
reason to wrestle with the beast that is the BLL?

Lisp envy?


Or otherwise, working with an IDE where creating a new function or
method is significantly more time consuming than just typing the
function signature in a text editor, and therefore where it would be
advantageous to be able to use anonymous functions.

 

[SchighSchagh]

Kai-Uwe Bux wrote:
> We cannot overload the dot-operator (what a shame!). Therefore, the magic
> functor _1 cannot forward member functions.
>
> You can try to use bind to make it work. So, instead of _1.get<0>, you would
> have a monstrosity like:
>
> bind( &whatever_type::get<0>, _1 )
>
> (or worse: I did not try it.)

What about the old trick

(*&_1).get<0>()

Normally this should work too. Of course, it implies that the operator&
of the object behind _1 is not overloaded in some magic way.

(I did not test it, since I have no boost::lambda currently running here.)



Marcel

Marcel, your "old trick" didn't quite work, but

(&*&_1)->get<0>()

does seem to work for me. ^_^