Copy constructor converts from const to non-const?

Consider the following :

class A
{
public:
    int xx;
    A(const A& other)
    {
        cout << "A cctor" << endl;
        /*  do some st开发者_StackOverflow中文版uff */
    }

    A(int x) : xx(x) {}  /* conversion constructor */

    };


int main()
{    
    A a = 1;
    A other = a;
    return 0;
}

Is it right to say that CCtor converts from const to non-const in this case (and also in general) ?

Thanks ,Ron

A copy constructor creates a new copy of an existing object, that object may or may not be const. The const in A::A(const A& other) just says we are not going to change other in the copy ctor. Indeed if you attempt to modify other inside the ctor the compiler will moan at you.

The created object also may or may not be const depending on how you declare it.

No idea what you mean. A(const A&) is a typical copy-ctor, which has a "read-only" access to its only argument. If you pass anything const, everything is fine. If you pass anything non-const, for ctor it becomes const. A a = 1 is a conversion ctor, as you said. A other = a is a copy ctor. What's the question?

Regarding your question's title, in C++ there's no fair way to convert const to non-const.

class A
{
public:
    int xx;
    A(const A& other)
    {
        cout << "A cctor" << endl;
        /*  do some stuff */
        // other is const here - you can only call its
        // const methods and read all its data members            
    }

    A(int x) : xx(x) {}  /* conversion constructor */
        // at this point, x is not const, but it's a copy
        // of an object you've passed here, not the object itself
        // you can change x, it just doesn't matter - you
        // change the copy
    };


int main()
{    
    A a = 1; // a is not const, 1 is passed "by value", since it's primitive type
    A other = a; // a is not const, other is not const, a is passed by const reference
    return 0;
}

Constructor initializes a new copy. And there is no problem in copying from a constant.

No conversion is involved.

What do you mean by CCtor converts from const to non-const?

If you mean, the non-const object gets created from the const object by invoking the copy-constructor, then yes. But that doesn't mean the const-object itself becomes non-const inside the copy-constructor (or at the call site). It only means that the newly constructed object is created by copying the existing object which is passed as const reference to the copy-constructor.

No the copy constructor creates an copy of the class object by taking another class object as the parameter.

Since in order to construct the new object being passed as parameter is not required to be modified it it passed as an const.

No, it's not converting to a non-const object. Consider this:

A a(42);
const A another = a;

Here, another is a const object, created from a non-const object.

More important, however, is that a constructor creates a new object from an existing one. Whether that new object is const or not does not depend on the existing object. All four possible combinations of const/non-const old/new objects are possible.

In the sense that the A(int) constructor converts from int to A, yes it's true that your copy ctor A(const A&) "converts" from const A to A. For that matter it also "converts" from non-const A to A, since the const reference parameter can bind to either.

And since the same constructor is used to create a const object as to create a non-const one, that copy ctor can also "convert" from A or const A to const A.

I've used "convert" in quotes just because converting from a type to itself or a cv-qualified version of itself is perhaps a confusing use of the term, normally you just call that "copying" rather than conversion.

The constructor parameter can bind to an instance of a derived class of A too, so you might say that it converts derived classes to A. That's normally called "slicing".

Strictly speaking it's not the copy ctor itself that converts anything, but a conversion to A (whether a cast or an implicit conversion) does depend on using a matching constructor. So I suppose the constructor can claim a large part of the credit.