Click here to Skip to main content
14,865,476 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
if we not create a copy constructor then compiler provide a default copy constructor.my question is that why compiler provide a default copy constructor? can a programmer or user get some benefit if compiler provide a default copy constructor?if yes then how?
Posted

Without a default copy constructor, programmers would need to write one for every type that might take part in copy construction. And in most cases, specially with POD types, the most common form of copy construction is basically just what the compiler auto generates for you.
   
Comments
Sergey Alexandrovich Kryukov 19-Jan-11 14:18pm
   
It's not "copy" constructor. You see the difference? A copy constructor always has a parameter, which is uses as a source of copy operation.
The only default constructor is parameterless.
Nish Nishant 19-Jan-11 14:21pm
   
What do you mean?
Nish Nishant 19-Jan-11 14:22pm
   
Ah okay. Yeah but the copy constructor that's compiler generated is most commonly referred to as a "default copy constructor". Not to be confused with the default constructor, but I don't think the OP is confused about that.
Sergey Alexandrovich Kryukov 19-Jan-11 14:22pm
   
Ok, I'll explain in my answer.
Nish Nishant 19-Jan-11 14:24pm
   
A more accurate term would be "compiler generated copy constructor" but if you do a quick google, you'll see that lots of folks refer to it as "default copy constructor". It's just a matter of terminology.
satyabrat subudhi 19-Jan-11 14:28pm
   
My Question is that how and what benefit we get by using copy constructor
although there is a default copy constructor?Explain briefly and deeply with real life project.
Nish Nishant 19-Jan-11 14:33pm
   
There is no need to look at a large project to understand why it's needed. If a and b are objects of the same type, then to do this:

a = b;

...the type needs to have a copy constructor. The copy constructor will also come into play when you call methods with copy by value arguments.
Sergey Alexandrovich Kryukov 19-Jan-11 14:38pm
   
Or, I'm sorry, and thank you, you're right, I messed up things. -- my answer fixed.
Nish Nishant 19-Jan-11 14:39pm
   
No problem. BTW the OP made at least 4 other threads on the same topic. I have deleted them, but it's almost beginning to seem like spam.
satyabrat subudhi 19-Jan-11 14:53pm
   
really this answer clear my doubt.can you describe it briefly? please
Sergey Alexandrovich Kryukov 19-Jan-11 14:38pm
   
Five from me.
T2102 20-Jan-11 18:15pm
   
You can define a=b with an assignment operator
Nish Nishant 20-Jan-11 18:30pm
   
Yes, but again because the compiler generates one for you.
T2102 20-Jan-11 18:47pm
   
Yes, but you could overload an assignment operator directly without defining a copy constructor. For instance if you used matrices, you could create an assignment operator for notational convenience. However, you might not want implicit copy construction/conversion performed.
Nish Nishant 20-Jan-11 20:03pm
   
Yes, that is correct. My example above should have been:

SomeType a = b;

and not:

a = b;

I didn't mean to confuse the OP by bringing in assignment operators into this.
Despite the marketing reasons every one can expose (self-generated copy copy constructor existi because are good to ... or because it would be bad to ...) the history has a clear answer.
After C++ introduced the concept of "objects" and made the struct to fall into it together with the classes, that was the sole way to retain C semantical compatibility about the copy and assignment of structs.

In C, if you have
struct A { int x; };
A function() { A a; a.x=1; return a; }
A a1;

You must be able to compile
a1 = function();

That requires the local a to be copied into a temporary residing in the outer scope to be soon later assigned to the a1 variable.
Without copy and assignment operations, plain C programs could not be compiled by C++.

Whether it was a good or bad choice extending this behavior to classes ... that's all another problem.
   
A compiler provides default constructor which is a parameterless and a default copy constructor which does shallow copy.

C++
class MyClass {
    int A, B;
public:
    MyClass() {}
    MyClass(MyClass &src) : A(src.B), B(src.A) { }
    MyClass(int a, int b) : A(a), B(b) { }
};
//...

MyClass c0;
MyClass c1(2, 4);
MyClass c2 = c1;


If first two constructors are not supplied, they are assumed by default.
To initialize c0, you need first one, parameterless, to initialize c1, you need a constructor with 2 parameters (no default), to initialize c2
you need a copy constructor (A and B swapped intentionally), if you comment a copy constructor out, it will compile anyway (because the default works in this case), and A will go to A, B to B. :-)

The default constructor (the one without parameters) can be disabled by providing some dummy constructor and making it private. This is a known way artificially disable the ability to construct an instance at all -- especially needed because there are no notion of abstract class in C++
   
v3
Comments
satyabrat subudhi 19-Jan-11 14:27pm
   
Default copy constructor is present in c++.
Sergey Alexandrovich Kryukov 19-Jan-11 14:39pm
   
Sorry, I messed some things up, answer corrected. -- Thanks a lot.
--SA
Andrew Brock 19-Jan-11 22:07pm
   
"If first two constructors are not supplied, they are assumed by default."
Not quite, the empty constructor is not provided by the compiler if you provide your own constructor (other than the copy constructor)
Sergey Alexandrovich Kryukov 19-Jan-11 22:40pm
   
Andrew, read thoroughly, these statements do not contradict.
The compiler provides a default constructor if you don't write one explicitly for a couple of reasons:

- it's handy, if you hold everything by value then you can rely on the default constructor and woo-hoo, it all works

- C works this way. When you copy a struct in C does the compiler does a memcpy which has the same effect for built in types and PODs that a copy constructor has

Cheers,

Ash

PS: Just read Emilio's answer, he made the point I wanted to make, so move along, nothing to see here...
   
v2
The copy constructor is necessary for certain operations on STL collections. However, if you forgot to customize your copy constructor and the default copy constructor is utilized, you will find yourself needlessly wasting time on debugging. It is a much better practice to make the default copy constructor private and only make customized copy constructors public. Two minutes of laziness can cost you hours of maintenance.

Only if the class is essentially a struct would I consider utilizing a default copy constructor...
   
Comments
Aescleal 20-Jan-11 8:46am
   
While I'd agree that if you don't want your objects copied then use something like boost::non_copyable, there are loads more classes where using a compiler generated copy constructor is perfectly fine. The only times you need to write a copy constructor is when you're explicitly managing resources or need to record the act of copying.
T2102 20-Jan-11 18:03pm
   
It can work, but it's a bad habit.

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