Boost logo

Boost :

From: Fredrik Blomqvist (fredrik_blomqvist_at_[hidden])
Date: 2004-02-08 17:15:32

Brian McNamara wrote:
> On Sun, Feb 08, 2004 at 09:04:11PM +0100, Fredrik Blomqvist wrote:
>> What I want to add to the discussion is that I believe we need _two_
>> versions of return_type (or whatever we choose to call it).
>> Even though I like the power and syntax of the result_of<F(a,b)>,
>> I'd say it's not unreasonable to be in a situation where the
>> argument types (if any) simply aren't know. In such cases a plain
>> return_type<F> that would atleast make an "educated guess" would be
>> better than nothing.
> Here you go:
> template <class F> struct educated_guess_return_type
> { typedef int result_type; };
> It is right every time the actual return type is "int"! :)
> Seriously, can you show a case how "educated guess" is better than
> nothing? My instincts tell me that it's better to fail to compile
> than to guess the wrong type and start having random implicit conversions
> start kicking in.
Re-reading my previous post I can see I was unclear. I'm Not advocating a
solution that would never fail!
What I carelessly referred to by "educated guess" was to use the "old" pre
result_of techniques in the non argument-type version.
Basically piecing together function_traits<>, member_function_traits<> and
lastly a fallback to ::result_type. That technique doesn't require argument
types but would still cover many common cases. result_of may simply succeed
with deduction when this technique fails.

> In the (rare?) case where the return type of F doesn't depend on its
> arguments, then it either (a) it should probably just declare an
> F::result_type (in which case I think result_of<F> may work), or
The result_of implementation in the sandbox doesn't seem to do that (it
always requires the call syntax). But if it is possible that would be great
of course.

// Fredrik Blomqvist

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