Re: [boost] range/iterators/algorithms return type deduction (was: Re: range_ex: status?)

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-06-24 12:55:16

On Tue, Jun 24, 2008 at 6:12 PM, Mathias Gaunard
<mathias.gaunard_at_[hidden]> 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