Boost logo

Boost :

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-06-26 09:28:53


On Wed, Jun 25, 2008 at 2:46 AM, Mathias Gaunard
<mathias.gaunard_at_[hidden]> wrote:
> Giovanni Piero Deretta wrote:
>
>
>> 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 do not think there is any way, at compile time, to portably
distinguish between a const qualified reference and an rvalue return
type:

i.e, give

  struct bar{};

no kind of overloading/traits trick will let you distinguish between
these two 'foo':

  bar const& baz();
  bar baz();

you would need to overload your 'foo' (or better, is_reference)
detection function like this:

  template<typename T>
  true_type is_reference(T);

  template<typename T>
  true_type is_reference(T const&);

which of course is ambiguous (even dropping the const from the second
and letting the compiler deduce T as const bar).

Note that the above problem is present for both emulated and native typeof.

It is possible to do the detection at runtime using the ?: trick (see
BOOST_FOREACH), but AFAIK it cannot be done portably at compiletime.
Well, at leat until someone discover some dirty trick of course :). In
the meantime we will have to use the result<> protocol.

-- 
gpd

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk