Re: [boost] range/iterators/algorithms return type deduction

From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2008-06-24 20:46:22

Giovanni Piero Deretta wrote:

> To workaround the gcc bug you can hoist the type computation to an
> helper metafunction:
> 
>   template<class A, class B>
>   decltype(A() + B())  sum(A, B);  //fails with "sorry not implemented"
> 
>   template<class A, class B>
>   struct sum_result { typedef dectlyp(A(), B()) type; }
> 
>   template<class A, class B>
>   typename sum_result<A,B>::type sum(A,B); // ok
> 
> This way the "A() + B()" expression need not to be mangled, only the
> metafunction invocation which gcc handles just fine. It is
> inconvenient, but using decltype this way beats doing type deduction
> by hand.

Good to know.
I suppose Boost.Typeof could simply add a special macro for usage in
return types that does just that.

> AFAIK Boost.Typeof would deduce the wrong result type when a function
> returns a reference (wheter using emulation of native). I do not think
> it can be made to deduce references correctly.

Here is why I think implementing decltype on top of typeof is easy.

The expression exp could simply be wrapped in a foo(exp) with two
overloads of foo, one for T and one for T&. foo would then tag the
expression somehow to tell whether it was a reference or not.
Then after applying __typeof__, if the tag says the expression was of a
reference type, simply readd the reference qualifier.

As for the emulation mode, I have no idea about how it's implemented but
I assume it's manually removing reference qualifiers.

Boost.Typeof really should add a BOOST_DECLTYPE and not simply
BOOST_AUTO and BOOST_TYPEOF.

> I theory yes, but as boost.iterator adaptors allows the user to easily
> specify the value/reference type, strictly speaking there is no need
> of result_of support there.

transform at least needs to know what the result type of the function
object is.