Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2005-01-03 15:27:23


On Jan 3, 2005, at 1:49 PM, Thorsten Ottosen wrote:

>
> "Howard Hinnant" <hinnant_at_[hidden]> wrote in message
> news:C94D8AC6-5C17-11D9-BA03-003065D18932_at_twcny.rr.com...
> | On Dec 22, 2004, at 8:29 AM, Thorsten Ottosen wrote:
>
> | But with
> | an eye towards the future, I think decayed will still eventually
> | improve make_pair:
> |
> | template <class T, class U>
> | inline
> | pair<typename decayed<typename remove_reference<T>::type>::type,
> | typename decayed<typename remove_reference<U>::type>::type>
> | make_pair(T&& t, U&& u)
> | {
> | typedef typename decayed<typename
> remove_reference<T>::type>::type
> | dT;
> | typedef typename decayed<typename
> remove_reference<U>::type>::type
> | dU;
> | return pair<dT, dU>(std::forward<T>(t), std::forward<U>(u));
> | }
>
> why do you need remove_reference? If its needed, then maybe it should
> be
> part of decayed<T>'s behavior.

remove_reference is needed because (in the rvalue reference proposal) T
may be deduced as a reference type:

A a;
make_pair(a, a); // T and U deduced as A&
make_pair(A(), A()); // T and U deduced as A

I thought about putting remove_reference into decayed, but didn't think
it fit semantically because references don't decay. It turns out that
either I'm mistaken, or CodeWarrior decays references as an extension.
This compiles for me:

typedef int A[3];

void foo(int*) {}

typedef void F();

typedef void (*FP)();

void bar(FP) {}

void fun() {}

int main()
{
     A a = {};
     A& ar = a;
     foo(ar);
     F f;
     F& fr = f;
     bar(fr);
}

Comeau seems to like it too. So now it looks to me like the
remove_reference should go inside decayed, which happily does clean up
the proposed make_pair a bit. Are we having a good day or what?! ;-)

-Howard


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