"Howard Hinnant" <hinnant@twcny.rr.com> wrote in message news:E00E478E-5DC5-11D9-BC20-003065D18932@twcny.rr.com... | On Jan 3, 2005, at 1:49 PM, Thorsten Ottosen wrote: | | > | > "Howard Hinnant" <hinnant@twcny.rr.com> wrote in message | > news:C94D8AC6-5C17-11D9-BA03-003065D18932@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) [snip] | > 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 ok, I probably need to read up on move-semantics :-) I usually think of T as the deduced type in expressions like const T& etc. (To be honest, I don't fully get why the return type of std::forward() and std::move() can both be T&&, yet be different :-) ) | 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: [snip] I dunno, IFAIK, the term decay is used when an array decays to a pointer and the original type is lost. I'm not sure if that is true with function pointers (ok, you loose the original address as a CT-value, but....). | 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. hm... you can always use a referece where a value is expected: the referenced value is copied. To get the behavior of the make_pair() example, you need to say void foo(int*&); void bar(FP&); | Are we having a good day or what?! ;-) We sure are :-) Anyway, the problem of the reference type doesn't seem to be a problem before we introduce move-semantics; when we do that, decay<T>::type should strip any reference IMO because it will be the most wanted behavior. br -Thorsten