CODEWITHSUNDEEP
c++constants
john
john

Reputation: 8027

Adding const correctness

I have some code which has been written without regard for const correctness. Are there any circumstances in which changing this

class X
{
public:
    X(X& rhs); // does not modify rhs
    ...
};

to this

class X
{
public:
    X(const X& rhs);
    ...
};

would change the behaviour of an existing program? I know this change will allow code which doesn't currently compile to compile, but I'm interested if there is any circumstance in which code that already compiles would change it's behaviour.

Similar question, is there any merit in making this change instead?

class X
{
public:
    X(X& rhs); // does not modify rhs
    X(const X& rhs);
    ...
};

Upvotes: 4

Views: 158

Answers (4)

Björn Pollex
Björn Pollex

Reputation: 76876

djechlin is making an important point in his answer, although somewhat unclear, so I will try to explain better.

The constness of an object or reference affects overload resolution. For instance, if you have an object with a const based overload of a member function, different overloads will be chosen:

struct foo {
    void do_stuff();
    void do_stuff() const;
};

int main() {
    foo f;
    const foo& fr = f;

    f.do_stuff();   // calls non-const version
    fr.do_stuff();  // calls const version
}

Now, if one of the overloads has side-effects the other doesn't, you'd get different behavior after changing the signature, given that (or rather even though) the program compiles fine.

Upvotes: 0

Pixelchemist
Pixelchemist

Reputation: 24956

In fact a copy constructor should, imho, always take a const reference as its argument.

X(X& rhs) { } // does not modify rhs

This does not allow to copy const objects and hence the following code will not compile. While non-const objects can serve as const arguments, the other way round is impossible

X const test;
X new_x(test);

I can't imagine why someone should preclude the copy of a const object.

Concerning the changes you want to make: Does the copy constructor rely on any X member function that is defined non-const?

This will work like a charm but permit copying const objects:

class X
{
private:
  int a;
public:
  X(X &rhs) { a = rhs.value(); } 
  int& value (void) { return a; }
};

The next example will not compile since rhs is const but value() is not const.

class X
{
private:
  int a;
public:
  X(X const &rhs) { a = rhs.value(); } 
  int& value (void) { return a; }
};

If you want to make your class const correct you'll probably have to examine the whole class. It should only affect your in-class-implementations. Since I don't know a case where external code should rely on "non-constness" of a class member function. Except when non-const-references are returned by any public member-functions as in my example.

The following snippet will do as intended.

class X
{
private:
  int a;
public:
  X(int const &b) : a(b) { }
  X(X const &rhs) { a = rhs.value(); } 
  int const & value (void) const { return a; }
};

But be aware that this will interfere with any code like:

X test(100);
test.value() = 12;

This would work using int& value (void) { return a; } but fails with int const & value (void) const { return a; }. You could of course provide both to be on the safe side.

Upvotes: 1

djechlin
djechlin

Reputation: 60828

For copy constructor I don't think so. But note that in general, yes, declaration of const can affect which method is called. The only example that comes to mind is with array overloading - see e.g. this question.

Upvotes: 2

rerun
rerun

Reputation: 25505

Since you are changing the class that has the copy constructor I am assuming you can inspect the copy constructors code. If you can make this change and the copy constructor does not give a compiler error you are probably good. One conor case to consider is what the copy assignment operator does as there is no assurance which will be called especially in optimized code. So also make sure that your copy assignment will work with a const parameter.

Upvotes: 0

Related Questions