Re: [boost] boost::result_of and C++03

From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2008-04-05 20:23:07

On Sat, Apr 5, 2008 at 6:21 PM, Eric Niebler <eric_at_[hidden]> wrote:
> Peter Dimov wrote:
> > struct make_tuple
> > {
> >     template<class X> tuple<X> operator()( X const & x ) const
> >     {
> >         return tuple<X>( x );
> >     }
> >
> >     template<class X> tuple<X&>
> >     operator()( reference_wrapper<X> const & x ) const
> >     {
> >         return tuple<X&>( x.get() );
> >     }
> > };
> >
> > you'll see that it's relatively easy to write a result_of specialization for
> > it. The references are an annoyance, sure. But the idea is that you start
> > with the function object and then derive its result_of, not vice versa.
> >
> > Maybe I'm missing something else.
>
>
> Sure, in isolation this works, but let's look at how this composes. Here
> is a template that takes two unary TR1 function object types and
> composes them.
>
>
> template<class F1, class F2>
> struct compose
> {
>   template<typename Sig>
>   struct result;
>
>   template<typename This, typename Arg>
>   struct result< This( Arg ) >
>   {
>     typedef typename result_of<
>         F2( typename result_of< F1(Arg) >::type )
>     >::type type;
>   };
>
>   template<typename Arg>
>   typename result_of<
>       F2( typename result_of< F1(Arg const &) >::type )
>   >::type
>   operator()( Arg const & arg )
>   {
>      return F2()(F1()(arg));
>   }
>
>   // And a non-const overload, too.
> };
>
>
> I think that's right so far. Now imagine a simple identity function
> object, that just returns its argument unmodified:
>
> struct identity
> {
>   template<typename Sig>
>   struct result;
>
>   template<typename This, typename Arg>
>   struct result<This(Arg)>
>   {
>     typedef Arg type;
>   };
>
>   template<typename Arg>
>   Arg const &operator()(Arg const &arg)
>   {
>     return arg;
>   }
>
>   // and a non-const overload, too
> };
>
>
> Now take a look at what happens when I do this:
>
>   BigObject const obj;
>   compose< identity, make_tuple >()( obj );

I've seen something like this before. Isn't the issue here that you
want the functor to store a const reference to its argument in the
tuple, but the functor implements call-by-reference using
reference_wrapper? Then isn't that a job for cref?

compose< identity, make_tuple >()( cref(obj) );

I don't know if this helps, because I don't exactly see what this has
to do with lvalues/rvalues, but here's a make_tuple that respect the
constness of the reference_wrapper. It plays nicely with result_of and
apparently works with your identity and compose functors. (tested on
gcc 3.4; the obj isn't copied)

struct make_tuple {
    template<typename Sig> struct result;

    template<typename This, typename Arg>
    struct result<This(Arg const&)> {
        typedef tuple<Arg> type;
    };

    template<typename This, typename Arg>
    struct result<This(reference_wrapper<Arg> const&)> {
        typedef tuple<
            typename unwrap_reference<Arg>::type &
        > type;
    };

    template<class X>
    typename result<
        make_tuple(X const&)
    >::type
    operator()(X const& x) const
    {
        return tuple<X>(x);
    }

    template<class X>
    typename result<
        make_tuple(reference_wrapper<X> const&)
    >::type
    operator()(reference_wrapper<X> const& x) const
    {
        return tuple<
            typename unwrap_reference<X>::type &
        >(x.get());
    }
};

Is this anything like what you're looking for?

Note that there are specializations for result<> corresponding to
exactly the way the operator()s are overloaded, and the overloads use
result<> to specify they're return types. In a situation like this, I
find it easier to try to keep a specific one-to-one correspondence
between result<> specializations and overloads. It's a bit of a
manually convention, but as you both point out, without decltype
return type deduction can be tedious by nature.

Daniel Walker