Re: [boost] couple questions about LL

From: Jaakko Jarvi (jajarvi_at_[hidden])
Date: 2002-03-21 13:55:57

> 1. 4.3.: What is the reason for this restriction? 

The lambda functors take their arguments as:

template<class T>
... operator()(T& t)

If called with a non-const temporary, say 1, the deduced prototype will 
be:

operator()(int& t) 

and the compiler will give, "cannot bind references to non-const 
temporaries" error, which it must do, by the standard.

Why 1 is non-const rvalue?

1 is of type int, not const int. I guess the standard says that, can't 
remember have I checked that at some point, but at least that is the
type compilers give to 1.

> 
> 2. How difficult will be to make library more flexible in terms of max arity. 
> Could we use BPL, code generator or some other means to be able to have 
> to than 3 args?
To make it really flexible (like having a #define NUMBER_OF_PLACEHOLDER 
would require some work), but to increase the number of placeholders
from 3 to some other constant is not a big problem.

> 
> 3. 5.1: Is there way to explicitely define lambda function as local 
function. I.e.:
> 
> void foo() {
>    ?? F = _1 + _2;
> 
>    F( i, j );
> }

Yes, with Doug Gregor's the boost::function library, but the argument 
types must be then specified:

void foo() {
  boost::function<int, int, int> f = unlambda(_1 + _2);

  int i; int j;
...
  f(i, j);

The unlambda is needed, as there is a conflict between the function 
library and LL, as function uses the operator& to take the address of
the function object, but operator& is overloaded for lambda functors.

Doug, you think it could be resolved, so that unlambda would not be 
needed?

> 
> 3. 5.1.1:  Currying allows binding of FIRST argument only (I mean you can't
 bind second this way). Is it true? It probably should be documented then.
Can you elaborate?

> 
> 4. Is it true that standard require for_each function object not to 
modify it's argument? If true the reference to the standard should 
be provided.

This is not very clear. for_each is listed as a non-modifying sequence 
operation, so it kind of states that. 

> 
> 5. Did you do performance tests? Did you compare performace with other 
functional libraries. performance test should probably be added 
to the test section.

They are on the making. We are doing comparisons between STL compose2 
mess vs. lambda expressions vs. explicitly written function objects.
It seems that with the compilers
we are testing (KCC and GCC) lambda expressions have a small penalty
compared to explicitly written function objects (-5% - 20%), but STL 
compose stuff get 2-3 times slower when the complexity increases.
The expressions are arithmetic expressions having around 2 - 15 terms.

So the statements we make in the performance section seem to hold,
and we will add the test reports into the docs when we get them ready.

> 
> 6. 5.2.1.: List of operators that could not be overloaded does not seem 
correct.

Right, couple are missing. I'll rephrase the docs.

> 
> 7. 5.2.6.: why don't you mention (_1 ->* $B::foo ) by itself could I 
passed it as function object somewhere?

The question is not clear to me?

> 
> 8. 5.3.2.: did you mean set_j( int x ) CONST?

Oh yes!

Thanks for your comments,

Jaakko