On Tue, Jun 24, 2008 at 6:12 PM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
Steven Watanabe wrote:
Can't you use result_of?
As far as I can see, the current boost::result_of implementation doesn't use decltype or typeof. I suppose implementing decltype on top of typeof is not a big problem (you only need to check whether the expression is a reference or not) however both have problems with mangling when used in a return type, at least in GCC. That basically means you can't always rely on them working. I thought decltype didn't have those mangling problems, looks like it is a regression.
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. I'm not sure if this works in all cases though.
As for the correct way to do that, I suppose it should be possible to tell boost::result_type with a macro definition to use Boost.Typeof, which in turn can use either native or emulation.
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. IMHO Range_ex should just use result_of. It is to the provider of the functor (i.e. the range_ex user) the decision of implementing the TR1 result_of protocol or use a compiler which support decltype (I think that someone proposed a patch to have boost::result_of use decltype where available).
However range_ex only forwards algorithms and adaptors to Boost.Iterator and maybe the standard library. Maybe it's these that ought to use boost::result_of in the first place?
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. -- gpd