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.
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.
-- Shunsuke Sogame
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk