Question

As a general rule, I prefer using value rather than pointer semantics in C++ (ie using vector<Class> instead of vector<Class*>). Usually the slight loss in performance is more than made up for by not having to remember to delete dynamically allocated objects.

Unfortunately, value collections don’t work when you want to store a variety of object types that all derive from a common base. See the example below.

#include <iostream>  using namespace std;  class Parent {     public:         Parent() : parent_mem(1) {}         virtual void write() { cout << 'Parent: ' << parent_mem << endl; }         int parent_mem; };  class Child : public Parent {     public:         Child() : child_mem(2) { parent_mem = 2; }         void write() { cout << 'Child: ' << parent_mem << ', ' << child_mem << endl; }          int child_mem; };  int main(int, char**) {     // I can have a polymorphic container with pointer semantics     vector<Parent*> pointerVec;      pointerVec.push_back(new Parent());     pointerVec.push_back(new Child());      pointerVec[0]->write();      pointerVec[1]->write();       // Output:     //     // Parent: 1     // Child: 2, 2      // But I can't do it with value semantics      vector<Parent> valueVec;      valueVec.push_back(Parent());     valueVec.push_back(Child());    // gets turned into a Parent object :(      valueVec[0].write();         valueVec[1].write();          // Output:     //      // Parent: 1     // Parent: 2  } 

My question is: Can I have have my cake (value semantics) and eat it too (polymorphic containers)? Or do I have to use pointers?

Answer 1

Since the objects of different classes will have different sizes, you would end up running into the slicing problem if you store them as values.

One reasonable solution is to store container safe smart pointers. I normally use boost::shared_ptr which is safe to store in a container. Note that std::auto_ptr is not.

vector<shared_ptr<Parent>> vec; vec.push_back(shared_ptr<Parent>(new Child())); 

shared_ptr uses reference counting so it will not delete the underlying instance until all references are removed.