From: rogeeff (rogeeff_at_[hidden])
Date: 2002-03-18 09:52:09
--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> I think that the Lambda library should be accepted.
> * Semantics
> The two primary differences between the lambda bind and boost::bind
> 1. boost::bind uses mem_fn to support smart pointers:
> std::vector< boost::shared_ptr<X> > v;
> std::for_each( v.begin(), v.end(), boost::bind(&X::f, _1) );
How will it look like with LL?
> The above unfortunately doesn't work with lambda; the bind in
lambda is not
> a drop-in replacement for boost::bind (as I'd have liked.)
> 2. Function object arity issues.
> A boost::bind expression has the same arity regardless of context,
> bind(&X::f, _1) always has arity [1, +inf). In lambda, the same
> has a fixed arity that is context dependent; i.e. the expression by
> has arity of 1, but in the context _2 + bind(&X::f, _1) that same
> has arity of 2.
How will it look like with LL? I.e. how to define binary function
f(x,y) = g(x,x)?
> Bind issues aside, I my overall impression is that the library is
> I don't see for loops and try/catch blocks as necessary parts
> of a lambda library; of course this is only my personal opinion,
and I am
> free to not use the features I don't find appropriate, so this is
> major problem; it's only that this epic scope could prevent lambda
> being added to the standard library. ( Another feature I don't see
a need of
> is currying support. It seems added just because it's possible, not
> it solves a practical problem. I liked the original lean-and-mean
> from several years ago. :-) )
Second this. I can hardly imagine using of very complex function with
switch end exception handling expreseed as one expression in a
production code. What if I need to step into it in the debugger?
Though this is just my feeling, that need real usage to justify it.
> Peter Dimov
> Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk