From: Joel de Guzman (joel_at_[hidden])
Date: 2007-06-17 15:52:16
dan marsden wrote:
> The definition of Fusion polymorphic function object will be changed shortly
> to be consistent with boost.resultof. Instead of requiring a nested result
> metafunction of the form:
>
> template<typename T0, typename T1, ... typename TN> struct result { typedef
> xxx type; };
>
> A polymorphic function object will instead simply be required to suppport
>
> boost::result_of<F(A,B,...Z)>::type
>
> as a valid expression.
>
> This will break some Fusion client code, specifically, if you are using fold,
> accumulate, transform, or a lot of the components in the functional section
> of the library, you may need to make changes to support this change.
>
> The change should be entered into CVS head over the forthcoming weekend.
>
> Apologies to anyone whos code this breaks, but this should make things more
> consistent with the rest of boost going forwards.
Thanks Dan!
(CC'ing Doug)
Doug, I know the result_of interface is almost standard now, but I
still wonder about the redundancy of the function-object interface:
F::result<F(T1, T2,..., TN)>::type
Is there a rationale? F is redundant here. The former fusion result API
does not require the F. Now, for example, instead of writing:
struct square
{
template<typename T>
struct result
{
typedef int type;
};
template <typename T>
int operator()(T x) const
{
return x * x;
}
};
We have to write it as:
struct square
{
template<typename T>
struct result;
template <typename T>
struct result<square(T)>
{
typedef int type;
};
template <typename T>
int operator()(T x) const
{
return x * x;
}
};
I'm not complaining, we already bit the conformance bullet :P
Just wondering why the latter is superior to the former.
Regards,
-- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net