Boost logo

Boost :

From: shunsuke (pstade.mb_at_[hidden])
Date: 2007-03-21 17:43:16


Daniel Walker wrote:
> This isn't a bad idea, but I feel that result_of is a simple utility
> and doesn't merit an additional interface to provide for user
> extension. Users should simply provide result<>. Boost.Lambda is a
> special case partially because of long standing precedence and a large
> user base. It's been around for ages. I like Giovanni's suggestion for
> transitioning away from sig<> support.

> If/when lambda standardizes on
> result<>, the lambda related special cases in result_of can be
> removed.

It will break a code using not result_of but sig compatible functors?

Apart from politics, I prefer "virtual" to "switch", :-)
whether or not the "virtual"(that is, 'extend_result_of') is a public
interface.

> template<class F, class Arg>
> void g(F const& f, Arg& x)
> {
> typename result_of<
> F(F, Arg)
> >::type y = f(x);
> }

This usage of 'result_of' seems wrong.
You meant?
     typename result_of<
         F(Arg&)
>::type y = f(x);

> In the example above where functor f is lambda compatible according to
> the existing convention, calling f right away causes an error without
> the result_of patch even though delaying the call to f succeeds with
> the lambda patch.

Can the patch support a sig compatible functor
which is "nullary-callable" (e.g. lambda::constructor<>) ?

>> On the other hand, "result_of<lambda>" project will be
>> an interesting work. What does "result_of<bind(..)>" return?
>> I want to know it :-)
>
> This is kind of cool! First off, to literally use something like
> 'result_of<bind(functor)>::type' is illegal. Bind is not a constant
> expression. result_of requires a function/functor type.

I really want the type, which can be used with result_of.
Some considerations will be required.

> struct functor {
> BOOST_FIXED_ARITY_FUNCTOR_RESULT(2, A1)
>
> template<class Arg>
> typename result<functor(functor, Arg)>::type
> operator()(Arg const& a) const
> {
> return a;
> }
> };

I introduce <boost/detail/functionN.hpp> at Boost.Accumulators,
which seems very cool.

Regards,

-- 
Shunsuke Sogame

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk