Boost logo

Boost :

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

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

> 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

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,


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