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.