When does a programmer need to implement his own copy constructor?

      Though compiler automatically provides the default copy constructor, sometime a programmer needs to implement his own copy constructor. We can take up a case here:
  

       In the default constructor some memory allocation has been done for few data members and hence those will be created in the heap. In the destructor corresponding de-allocation code is there. Now if an attempt to copy an object is made, it won’t call the default constructor but it will call the default copy constructor which will copy the data member variable from stack and copy the pointers but won’t allocate any new memory space for the new copied object. So same pointers will exist in both the parent and copied object. This will not only create a great ambiguity but runtime error will occur when attempts will be made to delete both the objects. First object will get deleted properly. When it will try to delete the other object, the common pointer won’t exist and runtime error will come. Even if user stops the application it will try to delete all the objects in the memory and runtime error will occur. In a single word, copy constructor is needed to be implemented independently, when the parent object has some allocated memory in heap for some of its data member and that gets deleted by destructor. Copy constructor should consist that much of code for memory allocation for the newly created object.Apart from this, programmer can implement his own copy constructor to copy any other things, which he wants specifically.