Boost logo

Boost :

From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2007-03-21 22:27:05

On 3/21/07, shunsuke <pstade.mb_at_[hidden]> wrote:
> Daniel Walker wrote:
> > 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?

Yes. That's the reason lambda would support both for a time with sig<>
being deprecated. After a release or two (giving users plenty of time
to update their code) sig<> would be removed. This gives them a fair
warning and time to adapt.

> > 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);

Thanks for pointing this out. You're right, this is incorrect.

I thought this usage was awkward when I first saw it. I just thought
it was cool that my lambda changes worked at all and that's largely
due to the sound library design of Jaakko Järvi. I'll submit an
explanation and a revised lambda patch on the thread where I posted
the original.

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

Yes. I just tested it with lambda::constructor<>, and it does work.

> > result_of requires a function/functor type.
> I really want the type, which can be used with result_of.
> Some considerations will be required.

Oh, I misunderstood. I thought you wanted the type that result_of generates.

Everything regarding types that can be used with result_of is the same
as the current result_of documentation with two exceptions. First,
where the documentation says "F::result<F(T1, T2, ..., TN)>::type" add
'or F::sig<tuple<F, T1, T2, ..., TN> >::type'. Second, result_of
accepts any functor generated by a lambda expression; specifically any
type instantiated from lambda::lambda_functor<>. If/when lambda
standardizes on result<> instead of sig<> you could remove both
exceptions and revert the documentation back to it's current state.

> > struct functor {
> >
> > 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.

I looked for your file in the boost-sandbox cvs repository and
couldn't find it. Could you send a link?


Boost list run by bdawes at, gregod at, cpdaniel at, john at