Why compiler provides default copy constructor

Question

I wanted to know Why compiler provides default copy constructor..Whats the strategy behind that idea.

Thanks in Advance.

Answer 1

A few points:

It's important to be able to control if an object can or cannot be copied.

If you don't want that an object can be copied, then you can declare the copy constructor private (and in C++ 0x you'll be able to say =delete). This is unchanged with your proposal however, the problem is simply reversed, ie. you could foresee a question like: "Why doesn't the compiler generate a default copy constructor when it knows what to do?"

This will also be addressed in C++ 0x, as I believe there is an =default flag which will allow you to specify it:

class C {
public:
  C (C const &) = default;
};

It's beneficial to allow the compiler to implement the best possible version of the copy constructor.

Ease of use aside, today the compiler is able to choose the most efficient technique for copying the object. For example, it might just use memcpy with the object if it knows that that is safe to do so.

With your proposal, to achieve a similar optimzation today the compiler would need to analyze the constructor body to verify that it does nothing but shallow copy all the members. Not only is this non trivial, it can generally only happen when the constructor body is visible to all translation units.

In C++ 0x =default gets round this.

I wouldn't be surprised if, for C++ 0x, compilers and static analysis tools start generating warnings about "old style implicit default members".

Answer 2

I'm not sure what the "official line is" (don't have Strastroup's book near me) and I'm sure someone will dig it up.

However, in most cases shallow copies and default initialization is "good enough", so it's better for the compiler to provide them than to have the developerexplicitly write them.

If the developer wrote this trivial copy constructors and the fields later change, it is up to that user to make the changes and there could be serious errors if he forgets (e.g., what are these fields constructed as?).

By only having users write copy constructors when there really is a need to do something fancy (like deep copying), you reduce the frequency of these errors.

Answer 3

From The C++ Programming Language, Section 11.3.4 Copying

...for types where the default copy constructor has the right semantics, I prefer to rely on that default. It is less verbose than anything I can write, and people should understand the default. Also, compilers know about the default and its possible optimization opportunities. Furthermore, writing out the memberwise copy by hand is tedious and error-prone for classes with many data members.

Basically, I read that as the default copy constructor saves you the effort, saves you from making errors caused by tedium, and helps optimize your code by removing the the temptation to optimize it by hand (by letting the compiler do it).

Answer 4

I don't know why it was originally designed that way. But as a user I can say why I'm glad they did.

1. If you use all RAII or POD types, a copy constructor will do the right thing
2. Copy constructors don't require thinking or maintenance, they just work given #1

I feel the same way about the default assignment operator. Most people either a) define their copy constructor / equals operator incorrectly or fail to maintain it. I've removed a lot of bugs in C++ code by switching to RAII types and deleting hand coded operators / copy constructors.