Boost logo

Boost :

Subject: Re: [boost] Checking for return types (result_of) - redux..
From: Edward Grace (ej.grace_at_[hidden])
Date: 2009-08-21 10:58:01

Hi Steven,

Thanks for your response, I think it's going to save me a lot of
messing around!

On 21 Aug 2009, at 15:29, Steven Watanabe wrote:

> Edward Grace wrote:
>> So, I have nearly figured out what to do, however it seems --
>> deliberately in fact, that the behaviour of result_of<???> is
>> different when passed a function and a functor.
> The type of a function pointer is unsigned(*)(). The return type
> is easily deducible from the type of the function pointer.
> For function objects, you need to use result_type or result,
> since it is impossible to deduce the result type automatically

Ok, that's kind of what I suspected -- but I didn't know why.

>> struct one_functor {
>> // This is apparently needed if we want to use result_of<..> on
>> nullary functors like this.
>> // typedef unsigned result_type;
>> unsigned operator()() { return 1; }
>> };
> In the current standard it is impossible to deduce the result
> without using the result_type typedef.

At least this means I won't waste my time trying to figure out what
I'm doing wrong!

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? 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?


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.....

...but it's C++, they should be used to it by now (ducks and exits
stage left).

> In C++0x, result_of
> is specified using decltype, so it won't be necessary.

Rapidly I'm coming to the conclusion that I'm not going to bother
writing templated code until C++0x is finished -- there's (still) too
much missing. Boost does a good job of papering over many of the
cracks, but they are still there under the surface!



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