Re: [boost] Checking for return types (result_of) - redux..

Subject: Re: [boost] Checking for return types (result_of) - redux..
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-08-21 12:53:00

AMDG

Edward Grace wrote:
> It seems quite unedifying having to make sure the user adds some, 
> apparently arbitrary, magic typedef to their functors in order to make 
> sure it works.
>
> My original motivation was to form a helpful compile time assert for 
> the user, which I thought would be good practise. It appears all this 
> does is to shift a conceptually straightforward problem (make sure 
> your functor/function returns something) to an even more obscure one 
> "ordinary functions are fine but make sure you define a return_type 
> typedef in your functions oh.. and make sure the return type of the 
> operator()() is the same as that... " Then I have to add a way of 
> sanely catching if they have not done this - I doubt I can...  Crazy!
>
> Do you know if, boost::bind and or boost::function etc automatically 
> add this typedef?

Yes, they do.

> If so some of the pain (and errors) would be alleviated by the 
> automatic typedef.  I they don't, perhaps they should.
>
> To make matters worse (rhetorical); if I have a class with a set of 
> different functors each with a different return type how can I make 
> sure the magic typedef (result_type) is simultaneously correct for each?

In this case, you would need to use the more complex
result template.

struct square {
    template<class Signature>
    struct result;
    template<class This, class T>
    struct result<This(T)> {
        typedef typename boost::remove_const<
            typename boost::remove_reference<T>::type
        >::type type;
    };
    template<class T>
    T operator()(const T& t) const { return t * t; }
};

> So, my best solution -- I think -- is to make sure my 
> functions/functors are unary and of the form:
>
>   void function_body(double return&);
>
> that should be fairly easy to check for in all cases. To users it will 
> appears weird in the extreme of course.....

If all you are doing is checking the return type,
you are probly better off using Boost.ConceptCheck.

In Christ,
Steven Watanabe