Boost logo

Boost :

From: shunsuke (pstade.mb_at_[hidden])
Date: 2008-04-02 15:28:10

Giovanni Piero Deretta wrote:
> 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
> required.

I don't sure what lambda[] does.
Why not call bll::unlambda?
BTW, `regular` incurs a slight overhead, so that
I didn't adopt automatic "regular"ization in Oven.

>> (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++.

But real lambda abstraction introduces different syntax.

>> >> 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.

It is not a problem whether or not it is stateless.
The problem is whether or not Default-constructed one is callable without crash.
A default-constructed, regularized Boost.Lambda functor always crashes.

> 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?

A simple case is adapting a function-pointer.

> (for example, did you use this functionality when implementing oven?).

Oven functions in namespace scope are neither stateful nor pointers,
so that every function might be implemented using `static_`
without complicated macros.

> 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.

I'm really afraid that those macros may keep users away from the library.


Shunsuke Sogame

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