Boost logo

Boost :

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, gregod at, cpdaniel at, john at