multiple copy constructors

[Glen Able]

Any ideas why compilers seem to give warnings about multiple copy
constructors e.g.

class A
{
public:
A(A& a);
A(const A& a);
};


Also, are there any other forms which would constitute a copy ctor?

thanks.

 

[David Rubin]

Any ideas why compilers seem to give warnings about multiple copy
constructors e.g.

class A
{
public:
A(A& a);
A(const A& a);
};

The problem is that a two functions cannot be differentiated solely on the basis
of the 'constness' of their arguments.

/david

 

[Guillaume Brocker]

The problem is that a two functions cannot be differentiated solely on
the basis of the 'constness' of their arguments.

That's right. Furthermore, IMHO, it's non sens to pass a non constant
parameter to a copy constructor, since the copy constructor's role is to
only make a *copy* of the passed parameter.

So there is absolutely no reason to have a constructor like this:

A(A& a)

 

[John Harrison]

That's right. Furthermore, IMHO, it's non sens to pass a non constant
parameter to a copy constructor, since the copy constructor's role is to
only make a *copy* of the passed parameter.

So there is absolutely no reason to have a constructor like this:

A(A& a)

std::auto_ptr has a copy constructor exactly like that.

It's not common, but it is legal and very occasionally useful.

john

 

[Rob Williscroft]

David Rubin wrote in

The problem is that a two functions cannot be differentiated solely on
the basis of the 'constness' of their arguments.

No, all the usual overload resolution rules apply:

#include <iostream>

struct X
{
X() { std::cerr << "X::X()\n";}
X( X const & ) { std::cerr << "X::X( X const & )\n"; }
X( X & ) { std::cerr << "X::X( X & )\n"; }
};


X f() { return X(); }


int main()
{
using namespace std;
X const x = f();
X y( x );
X z( y );
}

I get:
X::X()
X::X( X const & )
X::X( X & )

With all 5 compilers I tried, for some reason VC 7.1 gives
the warning descibed by the OP. I can't think of a good reason
for it, but VC 7.1 has a whole bunch of backward compatability
features that often don't make sense, so maybe thats it.

Rob.

 

[David Rubin]

David Rubin wrote in

Glen Able wrote:



The problem is that a two functions cannot be differentiated solely on
the basis of the 'constness' of their arguments.

No, all the usual overload resolution rules apply:
[snip]
With all 5 compilers I tried, for some reason VC 7.1 gives
the warning descibed by the OP. I can't think of a good reason
for it, but VC 7.1 has a whole bunch of backward compatability
features that often don't make sense, so maybe thats it.

You're right. After I posted my comment, I tried an example only to find I was
incorrect. Thanks,

/david