Boost logo

Boost :

From: Jaakko Jarvi (jajarvi_at_[hidden])
Date: 2004-03-08 18:30:40

On Mar 8, 2004, at 5:45 PM, Gabriel Dos Reis wrote:

> Jaakko Jarvi <jajarvi_at_[hidden]> writes:
> Well, before this message provokes a deluge of mails, I would
> probably point out that I'm a big fan of lambdas; but realistically I
> don't see C++ brainwashing armies of programmers into lambdas. This
> lambda-conversion, if it were to happen, need not be done in a one
> single big-step. Just think about the perception of lambdas before
> the STL and after, say, 1998. If you optimize for the most common
> simple cases, then people will use it, get adicted and want more.
> That is essentially what STL did.
> But, I see we are in violent agreement on one fundamental point:
> lambdas in C++ should be bound to lexical scopes (e.g. implemented by
> local classes). That provides opportunities for efficiency and they can
> be effectively optimized (with the hope that compilers understand the
> semantics of scopes, which some of them do). If you let the
> possibility to escape by default, compilers would have more difficulty
> optimizing and would provide less effective support. This has been
> done before. The experience was not that conclusive[2].

Yes, we're in agreement. We just have to define the 'most common simple
case' :) :)

Seriously, with built-in lambdas we should be able to provide something
that is more, or at least as, convenient than BLL or bind,
and having to do things like lambda lifting for cases where BLL and bind
would offer a straightforward solution seems unsatisfactory.

So I'm just wondering whether there is something in between the "no
reference to outside scopes" and full closures, which would hit the
sweet-spot for C++ better.

Some visible client side syntax would be fine, and probably good,
to explicitly state what to do with such references (copy, create
a reference, ...)

> | And it seems that in the inner lambda, x would be a variable from an
> | outer scope
> | with automatic storage, just like i is, and would therefore have to
> be
> | rejected
> | by the current local class rules.
> Hmm, I don't get that one. "x" in the inner lambda is the "x" bound
> by the outer (auto x). Therefore it is not rejected.

 From the point of view of the inner lambda, that is "defined in outer
Consider the following.

Here's the same thing simplified even more (and with more conventional
lambda syntax
for clarity, not to be considered as a suggestion for C++).

void foo(int x) {
   lambda a. x; // rejected, referring to x which is defined in an outer

void foo(int x) {
   (lambda a. (lambda b. a)) (x); // now x is ok, but if you convert
(lambda b. a) to a
                                  // local class, then a is a reference
to variable with automatic
                                  // storage, and would be rejected

Dave's going to throw us to std.c++.moderated or elsewhere soon, so we
may better take this
off-line soon :)

   Best, Jaakko

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