> -----Original Message-----
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Wednesday, July 02, 2008 3:55 PM
> To: [email protected]
> Subject: Re: error on tuple copy ctor
>
> Eric Lemings wrote:
> >
> >
> >> -----Original Message-----
> >> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of
> Martin Sebor
> >> Sent: Wednesday, July 02, 2008 3:18 PM
> >> To: [email protected]
> >> Subject: Re: error on tuple copy ctor
> >>
> > ...
> >>> Should we add the ctor even if the standard does not
> >> (currently) specify it?
> >>
> >> I don't think it's needed or desirable. In the test case I
> >> posted, we want to call the const T& overload.
> >
> > That's the only workaround I can think of. You have another one in
> > mind?
>
> A workaround for what? This is a valid definition of
> a CopyConstructible and MoveConstructible class (like tuple):
>
> struct S {
> S (const S&);
> S (S&&);
> };
>
> I don't see why S would need another copy ctor with the signature
> of S(S&). I realize tuple is quite a bit more complicated than S,
> too complicated for me to understand why the ctor might be
> necessary if, if fact, it really is. Could you show in a small
> isolated example the problem that this ctor works around?
It would probably bind as expected if not for the template ctors in
tuple. Apparently the compiler will prefer binding to a template ctor
any chance it gets because the constructed type and argument types are
"better", if not exact, matches in a template ctor. Not so for trivial
copy ctors.
For binding to a `S (const S&)' ctor given an object value of S, there
is an implicit const conversion involved.
Here's a small test case to illustrate:
#include <iostream>
using namespace std;
struct S {
S () {}
S (const S&) { cout << "trivial copy ctor called" << endl; }
template <class T>
S (T&&) { cout << "templated move ctor called" << endl; }
};
int main () {
S s1;
S s2 (s1); // trivial copy or templated move?
return 0;
}
Brad.
