Why copy constructor is passed by reference not by pointer

Question

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.

Regards,
Joy

Posted 11-Dec-13 18:44pm

joyjhonson

Add a Solution

4 solutions

Solution 1

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 [^]

Posted 11-Dec-13 18:56pm

TrushnaK

Comments

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]

Solution 2

hi,
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 :

C#

// 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.

Posted 11-Dec-13 19:30pm

chandanadhikari

Updated 11-Dec-13 19:34pm

v2

Comments

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.

Solution 3

// 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);

Posted 11-Dec-13 20:54pm

Eugen Podsypalnikov

Updated 12-Dec-13 5:09am

v4

Comments

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
{
public:
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
https://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8l.doc%2Flanguage%2Fref%2Fcplr390.htm

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 http://www.cplusplus.com/articles/y8hv0pDG/

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
{
public:
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 (http://en.wikipedia.org/wiki/Copy_constructor#Definition) :
"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
{
public:
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;
public:
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

Read!

Understand!

Stop Posting!

Good Bye!

Eugen Podsypalnikov 13-Dec-13 4:31am

You are wellcome, Stefan :)

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

Ciao.

[no name] 13-Dec-13 3:29am

Nice link.

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

Stefan_Lang · Accepted Answer · 2013-12-12T04:42:00

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.

C++

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

void foo() {
   cVec a(3.14, 2.71);
   cVec b(a + a); // now try and pass that by pointer!
}