The const in the copy ctor

[mescaline]

Hi,

I can't understand why there is a "const" for a copy constructor
declaration:
X(const X & X1)

When I deine my Copy ctor to be X(X& X1) i.e. avoiding the const still
things remain the same. However every example I see, there is this
extra "const".

Why is adding the const important here? Any explanations welcome

m

 

[Jeff Schwab]

Hi,

I can't understand why there is a "const" for a copy constructor
declaration:
X(const X & X1)

So you can copy const objects.

When I deine my Copy ctor to be X(X& X1) i.e. avoiding the const still
things remain the same. However every example I see, there is this
extra "const".

In your code, you may not be copying any const objects of class X. Even
so, the const qualifier is a nice way of "promising" that the
copy-constructor will not modify the object being copied.

-Jeff

 

[Ralf]

The "const" in the copy ctor has two aspects:
1. Normally, it is unusual to change the original while making a copy. With
the "const" you are proposing not to change the original.
2. To have a reference to an constant object makes it possible to copy from
an constant original.

Ralf


www.oop-trainer.de

 

[Cy Edmunds]

Hi,

I can't understand why there is a "const" for a copy constructor
declaration:
X(const X & X1)

When I deine my Copy ctor to be X(X& X1) i.e. avoiding the const still
things remain the same. However every example I see, there is this
extra "const".

Why is adding the const important here? Any explanations welcome

m

Consider:

void afunc(const Fred &f)
{
Fred f2(f);
...
}

If Fred's copy constructor is declared

Fred(Fred&);

then afunc won't compile.

Ordinarily copy constructors and assignment operators do not change the
arguments; i.e.

Fred f2(f); // does not change f
f2 = f; // also does not change f

This is indicated in the signatures which should be

Fred (const Fred &);
and
Fred &operator = (const Fred &);

respectively.

 

[mescaline]

So you can copy const objects.



In your code, you may not be copying any const objects of class X. Even
so, the const qualifier is a nice way of "promising" that the
copy-constructor will not modify the object being copied.

-Jeff

Thanks Jeff --
So adding a const is more of a compiler issue than anything else?
i.e.Does adding const improve the way in which the code is compiled?
- m.

 

[Jeff Schwab]

s welcome




Thanks Jeff --
So adding a const is more of a compiler issue than anything else?
Exactly.

i.e.Does adding const improve the way in which the code is compiled?
- m.

Nope. The optimizer usually doesn't even know anything about "const,"
and must determine on its own whether a variable can actually be changed
at run-time. Be careful to whom you tell this, though; there's a lot of
people out there using "const" with religious fervor, believing with all
their soul that this practice makes them efficient programmers.

-Jeff

 

[Jeff Schwab]

So adding a const is more of a compiler issue than

Exactly.

A pang of guilt compells me to add that by using const, you are implying
certain guarantees to the clients of your code. It is true that the
only time you *need* const is to make stuff compile, and that the
compiled code is unlikely to be any better for const having been used.
However, const is also a way to document your code's behavior. It's a
lot like adding a comment that says a variable will not be altered
within a certain section of code. Adding comments doesn't make your
code any more efficient, but it might make the programmers who use it
more efficient.

Ok, guilt assuaged.

-Jef