Boost logo

Boost :

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-04-02 13:05:31

On Wed, Apr 2, 2008 at 6:40 PM, shunsuke <pstade.mb_at_[hidden]> wrote:
> Giovanni Piero Deretta wrote:
> > I'm not saying that egg should support optionally-lazy functions [1],
> > it is ok if the lazy and non lazy variant have the same name. I just
> > want to be sure it is easy to define them.
> I did't adopt "optionally-lazy" functions.
> As you show, many functions take FunctionObjects as arguments
> so that protect or unlambda is needed everywhere.

Well, as I said, the lambda[] really helps to make lambdas stand up in
function calls. Also you have to wrap lambdas in 'regular' in may
calls anyway so you might as wel just use lambda[]. After a while it
becomes second nature, I simply use it even if it isn't strictly

> (I always follow the rationale "one name, one functionality".)

With real lambda abstraction, you wouldn't need a different name to
call a function inside a lambda expression. I was trying to
approximate it as much as possible in c++.

Anyways, I agree that optionally lazy functions might be confusing.

> Anyway, egg::unfuse with "contains_bind_expression<FusionSeq>" trait
> can easily implement such a optionally-lazy adaptor.
> >> After all, Boost.Lambda bind and placeholders are not usable here.
> >
> > Why? Detail please :)
> A functional call of `static_< always<F> >::type`
> is expanded to
> F()(a1,...,aN);
> If F is a function pointer type, this will clearly crash.
> A "regular"ized Boost.Lambda functor also will crash because of uninitialized error.
> After all, we need a lambda functor such that default-constructed one is callable.

I think that we would need a way to inspect a lambda expression
template and see if it is stateless (i.e. it is not closing over
anything stateful). If it is stateful, static_ might abort compilation
if initialized with 'stateless':

static_<always<F> >::type f = stateless; // does not compile if F is
not stateless.

As a bonus, a regularized, stateless, boost.lambda functor will
initialize itself with a default constructed lambda.

Figuring out if a lambda is stateless might be non trivial :) (but,
IMHO, feasible).

Anyways, I see that you take great care to guarantee static
initialization of stateful function objects. Do you really think this
is a case that is worth supporting? What are the use cases? (for
example, did you use this functionality when implementing oven?).

It seems to me that it complicates a lot the interface of the library
(with tons of ugly macros). I understand that this functionality is
opt-in (i.e. it is there only if you want it), but I feel
unconfortable. May be I'm worring too much, but I think that it really
makes the docs hard to follow.


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