CODEWITHSUNDEEP
c++pointersconstructor
Crispus
Crispus

Reputation: 23

C++ copy constructor issue with parent/child classes

I've run into a problem with copy constructors...I assume there is a basic answer to this and I'm missing something obvious - maybe I'm doing something entirely wrong - but I haven't been able to figure it out.

Basically, I have a parent class and child class. The parent class contains a vector of pointers to a (different) base class object. The child class wants to instead store pointers to objects derived from that base object.

Here's a pseudocode sample, if that helps:

// Base classes
class ItemRev {
  ...
}

class Item {

protected:

vector<ItemRev *> m_revPtrVec;

}


Item::Item(const Item &inputItemObj)
{
  // Copy contents of the input object's item rev pointer vector
  vector<ItemRev *>::const_iterator vecIter = (inputItemObj.m_revPtrVec).begin();
  while (vecIter != (inputItemObj.m_revPtrVec).end()) {
    (this->m_revPtrVec).push_back(new ItemRev(**vecIter));
  }
}

=========

// Derived classes
class JDI_ItemRev : public ItemRev {
  ...
}

class JDI_Item : public Item {

...

}

JDI_Item::JDI_Item(const JDI_Item &itemObj)
{
  // Copy contents of the input object's item rev pointer vector
  vector<ItemRev *>::const_iterator vecIter = (inputItemObj.m_revObjPtVec).begin();

  // The below does not work!
  while (vecIter != (inputItemObj.m_revObjPtVec).end()) {
    m_revObjPtVec.push_back(new JDI_ItemRev(**vecIter));
  }
}

The problem with the above is in the push_back() call in the JDI_Item copy constructor.

Given this setup, what should the child class's copy constructor look like? Do I even need a child class copy constructor? I assumed I did, because the copy constructor is creating new objects, and the parent copy constructor will create new objects that are not the type I want in the derived class (i.e., the parent object stores pointers to ItemRev objects, while the child object should store pointers to derived JDI_ItemRev objects).

Upvotes: 2

Views: 1953

Answers (1)

Richard Hodges
Richard Hodges

Reputation: 69882

As mentioned in the comments, there is probably a more succinct way to express this problem (i.e. your class structure needs some work).

However, if you want to do it this way, the easiest way to achieve it is to use a virtual clone() method in the base class of ItemRev, with overrides of it defined in derived classes.

e.g.:

class ItemRev {

  virtual ItemRev* clone() const = 0;
};

class JDI_ItemRev : public ItemRev {

  ItemRev* clone() const override 
  {
    // do your actual cloning here, using the copy constructor
    return new ItemRev(*this);
  }
};

Now, whenever you call clone() on any class derived from ItemRev, you will be returned an ItemRev* but it will point to a fully constructed derived class. You can of course get to the derived class's interface with static_cast<> or dynamic_cast<>.

...however...

derivation often seems like an easy win but it often turns out not to be. Inheritance should only be used if the derived class really is a type of the base class. Often people select inheritance when the derived class is a lot like a base class, or shares many characteristics with a base class. This is not the time to use inheritance. It's the time to use encapsulation.

In general, inheritance is evil.

On another note, you might find this link interesting.

Presentation on inheritance as an implementation detail

Upvotes: 1

Related Questions