From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-17 06:47:54
Kirit Sælensminde wrote:
> shunsuke wrote:
>> Kirit Sælensminde wrote:
>>> And finally, does the curry function itself need to be a macro?
>> When you need static-initialization.
>> BOOST_EGG_CURRY2(..) is, in fact, a knotty braced initializer,
>> which guarantees static-initialization.
>> 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)! :)
>>> Here is
>>> my implementation of curry2. I'd always assumed that a complete
>>> implementation would overload on the relevant "callable" types:
>> As mentioned above, non-numbered form `curry` might support the famous "callables".
>> It seems difficult to define "what is famous", though.
> 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.
No. It's basically just type traits to adapt built-in, Callable types to
sequential interfaces (so they can be handled regardless of their arity
without using preprocessor metaprogramming).
Further, as mentioned in my post you cited, it provides a workaround for
certain strange portability issues.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk