Click here to Skip to main content
15,038,451 members
Please Sign up or sign in to vote.
2.20/5 (2 votes)
See more:
Hello Everyone,

I have a question on copy constructor.

Why copy constructor is passed by reference not by pointer?

I am clear as to why it can not be passed by value.

Please help.


Some of the truth has been revealed in Solutions 1 and 2 (please ignore 3), but one of the reasons is that this allows you to pass things that can be converted or evaluated to your class type, such as expressions, without having to provide a temporary variable yourself.

class cVec {
   cVec(const cVec& other);
   cVec(double x, double y);
   cVec operator+(const cVec& first, const cVec& second);
   double x_;
   double y_;

void foo() {
   cVec a(3.14, 2.71);
   cVec b(a + a); // now try and pass that by pointer!
nv3 12-Dec-13 11:27am
Good point, Stefan. 5.
Since the copy constructor is generated by the compiler when not specified by the user, it make sense to use the same signature for user-defined copy constructor that is used for compiler-defined copy constructor.

If someone define a constructor that take a pointer instead of a reference, then if the caller forget to take the address of the object from which the new object is to be created, then instead of using user-constructor with a pointer, the compiler generated copy constructor (wioth a reference) would be used.

It also make sense to use a reference for consistency. For exemple, all operators like =, ==, <=, += would normally be defined using references.

Refer below link:-
C++ Copy Constructor in depth [^]
Stefan_Lang 12-Dec-13 10:21am
A constructor that takes a pointer as an argument is, by definition, not a copy constructor.

[edit] Sorry, just realized that you were responding to the OPs statement rather than making your own [/edit]
first try to understand what is a reference and when is it needed .
References are variables that act as an alias to another variable.References are implicitly const so they must be given a value upon declaration.

First, Const references are often used as function parameters because const references allow us to access but not change the value of an object, they can be used to give a function access to an object, but give assurance to caller that the object will not be changed at all by the function.

Secondly, a reference acts like a const pointer that is implicitly dereferenced.
Because references always “point” to valid objects, and can never be pointed to deallocated memory, references are safer to use than pointers. Thus the reference should generally be preferred. Pointers should generally only be used in situations where references are not sufficient .So, to prevent memory corruption issues References are preferred to pointers.

Taking both these factors we can give a copy-constructor like :
// Copy constructor
    MyClass(const MyClass &cSource)
        m_nVariable1 = cSource.m_nVariable1;

Thus the source object being passed is never modified within the copy-constructor and is used solely for read-only purposes.
Stefan_Lang 12-Dec-13 10:28am
Voted 4. Would have been 5 if not for your insistence to bind 'const' and 'reference' into one syntactical element. You're correct of course, that a reference itself can't be changed. However, you can pass a non-const reference to a function and thus allow it to change the value that the reference points to!
chandanadhikari 13-Dec-13 0:17am
thanks for the input Stefan_Lang.
nv3 12-Dec-13 11:33am
As Stefan already said: References come as const and non-const varieties. So your claim that all references are const is not true.

And references do not always point to a valid object. It is easy to construct a reference that points to invalid memory. So working with references does not eliminate the problem of dangling pointers. However, while passing a NULL-pointer as argument is a legal thing in C++ there is no such thing as a NULL-reference. You can compare a pointer with the value NULL, but you can't do that with a reference. Hence, passing an argument by reference is a strong indication that this argument is not optional.
chandanadhikari 13-Dec-13 0:17am
thanks for the input nv3.
// Why copy constructor is passed by reference not by pointer?

I guess that the basic idea by Mr. Stroustrup
was the validity of the passed data and its simplified syntax :D

Of course, you can provide your own copy-constructors as well:
B b;
B a(&b);
Stefan_Lang 12-Dec-13 10:23am
You're passign a pointer in line two, and thus do not invoke a copy constructor.
Eugen Podsypalnikov 12-Dec-13 11:00am
I'm passing a comment above about some own copy-constructors as well :) :
class B
B(const B&);
B(const B*);
Stefan_Lang 12-Dec-13 11:16am
You missed the point: you rsolution does not in any way define or describe a constructor of any kind, let alone a copy constructor. Your spurious code example merely calls a default constructor and a non-default constructor which is not a copy constructor either. I don't see how that helps the OP.

Please note that while you can define a constructor that takes a pointer as an argument, that would not be called a copy constructor by definition. You can define as many constructors as you like, but only the one with the right argument type will be accepted as copy constructor.

None of this relates to the actual question though.
Eugen Podsypalnikov 12-Dec-13 11:21am
I have answered the question of OP (please see it in bold above).
My code is just for the question part "Why not ?"
And the text - for the part "Why ?"

You can have many copy-constructors
but only one of them - Default Copy Constructor, by Mr. Stroustrup :)
[no name] 13-Dec-13 3:01am
I think Stefan_Lang is strictly correct in the interpretation of "copy constructor" - default or not is irrelevant
Eugen Podsypalnikov 13-Dec-13 3:08am
I think Mr. Stroustrup is correct, it is the begin in my answer :)
Stefan is correct as well :)
And OP may use an own copy constructor per pointer, even so :D
[no name] 13-Dec-13 3:19am
Thanks for your reply. The issue is that "per pointer" is not a "copy constructor" because that term has a special meaning. That's the original question is it not.
Eugen Podsypalnikov 13-Dec-13 3:22am
But it ("per pointer") may be an "own copy constructor" :)
Stefan_Lang 13-Dec-13 3:22am
You're mixing up terms. Please read up on copy constructors, e. g. on

Also I don't see how your code explains "why not" - or anything. There is no explanation.
Eugen Podsypalnikov 13-Dec-13 3:25am
class B
B(const B&); // Why ? -Since it is a standard by Mr. Stroustrup :)
B(const B*); // Why not ? -Yes, you may do it as well :)
Stefan_Lang 13-Dec-13 3:29am
Please stop posting replies denying the facts I explicitely linked to without following and reading the linked text!

Again, that last constructor is not a copy constructor. Full stop. Quote from wikipedia ( :
"A copy constructor has as its first parameter a (possibly const or volatile) reference to its own class type."

Please stop posting false information.
Eugen Podsypalnikov 13-Dec-13 3:31am
There is no explanation about any wrong Information, sorry :)
class B
B(const B&); // Why ? -Since it is a standard by Mr. Stroustrup :)
B(const B*); // Why not ? -Yes, you may do it as well :)
Stefan_Lang 13-Dec-13 3:47am
"Because Stroustrup said so" is not an explanation.
As for the rest, check the links I posted.
Eugen Podsypalnikov 13-Dec-13 3:52am
// "Because Stroustrup said so" is not an Explanation

Realy ? I think so :) Please see below:

class A
int i;
A() : i(0) {}

A a1;
A a2(a1); // Here is the hidden Speach by Mr. Stroustrup

All other links just use the Speach, not more :)
Stefan_Lang 13-Dec-13 4:04am
I didn't think it was possible, but you keep making less sense with each posting...
Eugen Podsypalnikov 13-Dec-13 4:07am
Are you meening
the implicitly implemented constructor by Mr. Stroustrup
in the class above, Stefan ? :D
Stefan_Lang 13-Dec-13 4:14am
Implicitely defined constructors are not the topic of the OP, nor my arguments.

Why do you keep bringing up irrelevant topics?
Eugen Podsypalnikov 13-Dec-13 4:20am
Here is the answer for you, Stefan, and for OP:

The explicit form of the Standard copy constructor
MUST BE THE SAME to its implicit form, by Mr. Stroustrup :)
Stefan_Lang 13-Dec-13 4:23am
The OP already knows that it must be the same. So do I.
Eugen Podsypalnikov 13-Dec-13 4:26am
You and OP know
why it must be the same to the implicit form by Mr. Stroustrup
as well :D
Stefan_Lang 13-Dec-13 4:29am


Stop Posting!

Good Bye!
Eugen Podsypalnikov 13-Dec-13 4:31am
You are wellcome, Stefan :)

Now we know: "why ?" and "why not ?"

[no name] 13-Dec-13 3:29am
Nice link.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900