Copy Constructor in C++

Question

This is a general question that I've been asking for a while but couldn't get a clear answer to. Do I need to code a copy constructor for a class when all instance data fields in this class are standard built in C++ data types?

Answer 1

The types of the member variables is not important for that⁽¹⁾, their semantics are. The rule is simple:

If you don't provide a copy constructor, the compiler will try to generate one for you. This default-generated one will perform the default copy operation on all member variables. For class types, this means calling the copy constructor. For primitive types, this means a bitwise copy.

If the default-generated constructor does what you need, don't declare your own. If it wouldn't do what you need, declare one yourself. It is possible to create a class with non-primitive member variables and perfectly OK default copy semantics:

struct PersonId
{
  std::string surname;
  std::vector<std::string> givenNames;
};

Likewise, it is possible to create a class with primitive-type member variables where the default copy semantics would not be OK:

class UniqueNamed
{
  int id;
  UniqueNamed() : id(0) {}

public:
  UniqueNamed(const UniqueNamed &src) : id(src.id + 1) {}

  int getId() const { return id; }

  static UniqueNamed initial;
};

So it depends on the class's semantics, not on the types of its data members.

This touches the general concept of the semantics of copying, moving & wonership, and their implementations in C++. You might want to read something about the rules of zero, three, and five.

---

⁽¹⁾ Of course, if any member variable is of a non-copyable type, and you want your class to be copyable, you have to provide the copy constructor yourself, as the default-declared one would be defined as deleted.

Answer 2

If you don't code a copy constructor, there is a default one created that copy one by one each field of your class, calling their copy constructors if any.

For instance :

class Test {
public:
  int toto;
  char titi;
};

int main() {
    Test a;

    a.toto = 42;
    a.titi = 'a';
    Test b(a); // b will be initialized with same fields than a.

    return (0);
}

Be careful with this method: use it only on simple classes with, as you said, only fields from standard built in C++ data types.

The most common mistake here is when your class have a pointer field: The pointer is copied, but not reallocated, so you will have two instances of your class with a pointer on the same thing, and if one of them modify or delete it, the other one shall feel the consequences.

class Test {
public:
  std::string* field;

  Test() {
      field = new std::string("toto");
  }
  ~Test() {
      delete (field);
  }
};

int main () {
    Test a; // a.field is allocated.

    Test b(a); // b have the same pointer than a, as if you did b.field = a.field.
    // Here a and b destructors are called. They will delete the same pointers twice.
    // It will result as a segmentation fault.
    return (0);
}

Note: this is true for = operators as well if you don't overload it.

Answer 3

If you need the object to be copied by copying the value of each data member, then you don't need to write one; the implicitly generated one will do exactly that.

If you need something else to happen when you copy an object, or if something is preventing the implicit one from being generated (for example, a const data member) and you still want to be able to copy it, then you will need to write one.

Answer 4

In general copy constructor is created by compiler for you. You need to create one /and assigment operator/ only when there are special objects or pointers inside the class, or you wish to have special handling or to define special checks or other special behavior. Example for such object that will require a user-defined copy constructor is a file. Other example why you need a user-defined copy constructor is that the default one will just copy data pointers. This means they will point same objects/same chunk of memory/. If the original object was on the stack, when it gets out of scope the destructor will free the pointer in the original object, and will leave you with pointer that points to invalid memory chunk and you will have segmentation fault.

Answer 5

No, you don't if you are going to use it as POD (plain old data) object. Compiler will generate for you default copy constructor that behaves as you can expect it - just assigns all fields from one object to another.