Click here to Skip to main content
15,882,260 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 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?

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.
Share this answer
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.
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.
Share this answer
A compiler provides default constructor which is a parameterless and a default copy constructor which does shallow copy.

class MyClass {
    int A, B;
    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++
Share this answer
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.
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



PS: Just read Emilio's answer, he made the point I wanted to make, so move along, nothing to see here...
Share this answer
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...
Share this answer
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