Re: [boost] [interest] Egg, function object builders and adaptors

From: shunsuke (pstade.mb_at_[hidden])
Date: 2008-01-17 06:22:53

Kirit Sælensminde wrote:
>> Of course, Egg supports also:
>>
>>      typedef boost::result_of<T_curry2(int(*)(int,int))>::type T_curried_plus;
>>      T_curried_plus curried_plus = curry2(&::plus);
>>
>> No macros. But there is a function-call, which incurs dynamic-initialization.
>> You might notice that "static form" using macro and "dynamic form" using function
>> is nicely symmetric.
> 
> So the macro removed the first function call and actually writes a 
> function which is the curried version rather than perform the currying 
> at runtime? Now that *is* cool and seems to be a good enough reason to 
> have a macro (to me at least)! :)

Egg's ambition is to replace a normal function, which is statically-initialized.
Hence, with or without great optimizers, Egg has to offer FunctionObject which
is statically-initialized, I think.

> There is another Boost library out in 1.35, Boost.FunctionTypes, which 
> might be able to help as it has decomposition functions that work with a 
> wider range of callable function than for example Boost.Function does. 
> Maybe that can be leveraged against? I've not had a chance to delve into 
> it myself yet though, but Tobias Schwinger seemed to think it would 
> handle the higher order requirements I was playing with last time I 
> raised it on the list.
> 
> http://thread.gmane.org/gmane.comp.lib.boost.user/30665/focus=30762

With that libray, I could document "When Egg can automagically calculate function arity".
I bet clients use "numbered-form function" before they try to read my complex document, though.

FWIW, Egg works with PolymorphicFunctionObject, which is virtually standardized by tr1 result_of.

Regards,

-- 
Shunsuke Sogame