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.