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

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 developer explicitly 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 2

Because C++ is not garbage collected, it forces you to keep track of all pointer owners, which is in practice impossible to do, unless you simplify the problem by using lots of copying all over the place so at least you know who owns the copy, and incidentally makes your program slower than a garbage collected one. Auto-generated copy constructors are a nail in the coffin that was put there to hide the gaping hole to hell that is new and delete.

Answer 3

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 4

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 5

I think you're coming at it from the wrong direction - if the compiler could write a complete and correct 'default' copy constructor for every class or structure, then nobody would complain, would they? The trouble is, the compiler can't do that reliably, so for those cases you need to write your own, overriding the default.

Answer 6

If you have a struct being used by C code, a default copy constructor needs to be there to preserve C struct copying semantics.

Answer 7

From a related (but not same) question - Why don't C++ compilers define operator== and operator!=?:

Stroustrup said this about the default copy constructor in "The Design and Evolution of C++" (Section 11.4.1 - Control of Copying):

I personally consider it unfortunate that copy operations are defined by default and I prohibit copying of objects of many of my classes. However, C++ inherited its default assignment and copy constructors from C, and they are frequently used.

So the answer is that it was included reluctantly by Stroustrup for backwards compatibility with C (probably the cause of most of C++'s warts, but also probably the primary reason for C++'s popularity).

For my own purposes, in my IDE the snippet I use for new classes contains declarations for a private assignment operator and copy constructor so that when I gen up a new class I get no default assignment and copy operations - I have to explicitly remove the declaration of those operations from the private: section if I want the compiler to be able to generate them for me.

Answer 8

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.

Answer 9

Because otherwise, when you pass an instance by value, how could the compiler generate one?

Answer 10

Saving you time? If you have a simple class (ie if you can easily copy construct all its elements) you then don't need to write one.