"Thorsten Ottosen" wrote:

| - isn't parameter passing suboptimal for e.g. | boost::make_pair(0, 0)?

by suboptimal you mean performance-wise?

Yes. I mean passing all by references when value would be enough (e.g. for int). /Pavel

...

Any thoughts from the type_traits authors?

I think decayed is an excellent trait. Your implementation should be modified to also take care of functions converting into function pointers though. It's a shame about the const qaulifier in your example make_pair messing up the int[10] conversion to int*.

I agree that it should work for function to function-pointer conversions as well. I've attached a slightly improved version that gets your non-const make_pair working, also uses remove_bounds rather than the range lib traits (just to keep things in the type_traits family). Not sure about the "decayed" name, but I can't think of anything better right now.

This is a characteristic of pair, not make_pair. And it could be disabled by restricting the member template constructor in:

template <class T1, class T2> struct pair { typedef T1 first_type; typedef T2 second_type;

T1 first; T2 second; pair(); pair(const T1& x, const T2& y); template<class U, class V> pair(const pair<U, V> &p); };

such that is_convertible<U, T1> and is_convertible<V, T2>, which is a change I would support.

If we do that, then we should do the same for the tuple constructors as well. John.

On Jan 2, 2005, at 11:01 AM, John Maddock wrote:

...

This is a characteristic of pair, not make_pair. And it could be disabled by restricting the member template constructor in:

template <class T1, class T2> struct pair { typedef T1 first_type; typedef T2 second_type;

T1 first; T2 second; pair(); pair(const T1& x, const T2& y); template<class U, class V> pair(const pair<U, V> &p); };

such that is_convertible<U, T1> and is_convertible<V, T2>, which is a change I would support.

If we do that, then we should do the same for the tuple constructors as well.

Absolutely. In fact, I'd really like to go a step or two further (for C++0X, not tr1): Introduce a trait: template <class P1, class P2> struct tuple_convertible { static const bool value = ... }; Such that value is true only if both P1 and P2 are "tuple like" (there used to be trait for "tuple like"), and tuple_size<P1>::value == tuple_size<P2>::value, and for every element I in P1 and P2, is_convertible<tuple_element<I,P1>::type, tuple_element<I,P2>::type>. I.e. tuple_convertible answers true only if P1 and P2 are tuples of the same size and each member of P1 is convertible to the corresponding member of P2. And then pair could look like: template <class T1, class T2> struct pair { typedef T1 first_type; typedef T2 second_type; T1 first; T2 second; pair(); pair(const T1& x, const T2& y); // needed only for binary compatibility template <class U, class V> pair(U&& x, V&& y); // pair(const pair& p); // implicitly generated // pair& operator=(const pair& p); // implicitly generated pair(pair&& p); pair& operator=(pair&& p); template <class P> pair(P&& p, typename enable_if<tuple_convertible<P, pair>::value>::type* = 0); template <class P> pair(const P& p, typename enable_if<tuple_convertible<P, pair>::value>::type* = 0); template <class P> pair& operator=(P&& p); template <class P> pair& operator=(const P& p); void swap(pair&& p); }; Here is a move-aware pair capable of holding move-only types, of moving in heavy weight rvalues, of interoperability with all compatible tuple-like types, including tuple, array, complex, and simply other types of pair. is_convertible will answer correctly when asked about pair and some other tuple-like type. And explicit constructors of T1 and T2 will be respected as Pavel requests. And yes, I'd like to see at least tuple and complex outfitted similarly. array is a special case that may not be able to do this, unless we can start adding ctors to it via another core extension. Btw, I kind of like "decayed" for a name. -Howard

"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:crccb6$i7f$1@sea.gmane.org... | Howard Hinnant wrote: | | > Btw, I kind of like "decayed" for a name. | | It occurred to me that decayed falls into the "transformations between types" | category, and so should be in the imperative for consistency with the other | transformations: decay<T>::type. yeah, I agree. -Thorsten

I can't see your attachment; would you mind post it again?

Sure, updated slightly to include support for function types as well, probably broken compilers without partial-specialization support though... John.

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) | { | 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

Rambling a little bit today... I set up a little test: template <class T> struct A { A(const T&) {} }; template <class T> inline A<T> make_A(T t) { return A<T>(t); } void f() {} int main() { std::cout << typeid(make_A(0)).name() << '\n'; const volatile int i = 0; std::cout << typeid(make_A(i)).name() << '\n'; const int a3[3] = {}; std::cout << typeid(make_A(a3)).name() << '\n'; int a4[4] = {}; std::cout << typeid(make_A(a4)).name() << '\n'; std::cout << typeid(make_A(f)).name() << '\n'; std::cout << typeid(make_A("narrow")).name() << '\n'; std::cout << typeid(make_A(L"wide")).name() << '\n'; } This prints out (on my system): A<int> A<int> A<const int *> A<int *> A<void (*)()> A<const char *> A<const wchar_t *> I believe this output, using pass-by-value for make_A, can be considered "the gold standard" for decay<T>. And here's what you get if make_A simply uses pass-by-const-ref: template <class T> inline A<T> make_A(const T& t) { return A<T>(t); } A<int> A<volatile int> A<int[3]> A<int[4]> A<void ()> A<char[7]> A<wchar_t[5]> Using a decay that supports function->function pointer, and one that strips top level cv-qualifiers off of non-arrays, and non-functions, and using John's overload strategy: template <class T> inline A<typename decay<T>::type> make_A(T& t) { return A<typename decay<T>::type>(t); } template <class T> inline A<typename decay<const T>::type> make_A(const T& t) { return A<typename decay<const T>::type>(t); } I can get the original behavior: A<int> A<int> A<const int *> A<int *> A<void (*)()> A<const char *> A<const wchar_t *> As Thorsten points out, remove_reference has no bearing as T can not be deduced as a reference type in C++03. But fwiw, I can achieve this output with only one make_A overload using the rvalue reference (if now decay has remove_reference). template <class T> inline A<typename decay<T>::type> make_A(T&& t) { return A<typename decay<T>::type>(std::forward<T>(t)); } The single overload: template <class T> inline A<typename decay<T>::type> make_A(T& t) { return A<typename decay<T>::type>(t); } gets nearly a perfect score, handling const qualified objects correctly. Its only failing is that it won't bind to rvalues. The const T& overload by itself doesn't work either because it gets arrays wrong (turns them into const T*). This exposes a weakness in the overload strategy: It doesn't scale well. Consider John's suggested make_pair: make_pair( const F& f, const S& s ); make_pair( F& f, S& s ); This fails with: int a4[4] = {}; std::cout << typeid(std::make_pair(0, a4)).name() << '\n'; std::pair<int, const int *> intead of: std::pair<int, int *> You really need four make_pair overloads to cover everything: make_pair( const F& f, const S& s ); make_pair( const F& f, S& s ); make_pair( F& f, const S& s ); make_pair( F& f, S& s ); Now you should get the correct: std::pair<int, int *> In contrast, only one make_pair is required when using rvalue_references: make_pair( F&& f, S&& s ); -Howard

And this is really bad. I can't provide all these overloads in boost.assign for 2-5 arguements, say.

Sure you can. That's only 16 overloads. Use the preprocessor. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

Thorsten Ottosen wrote:

"David Abrahams" <dave@boost-consulting.com> wrote in message news:crf6sd$m1t$1@sea.gmane.org... | | > And this is really bad. I can't provide all these overloads in boost.assign | > for | > 2-5 arguements, say. | | Sure you can. That's only 16 overloads. Use the preprocessor.

AFAICT, up to 5 arguments would give 32 + 16 + 8 + 4 + 2 = 62 overloads.

You're right; what was I thinking?

That's a lot of code to parse in a header. How much will this affect compilation time?

Not much, based on what I've seen in the past, but you'll never know until you try it.

Given that the usage is minimal in the boost.assign I'm not so keen about doing this currently.

It's your party. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com