When should I use a vector of objects instead of a vector of pointers?

Question

I have a collection of polymorphic objects, all derived from my Animal class: Cat, Dog, and MonkeyFish.

My usual mode of operation is to store these objects in a vector of Animal pointers, like so:

std::vector< Animal * > my_vector;

my_vector.push_back( new Animal_Cat() );
my_vector.push_back( new Animal_Dog() );
my_vector.push_back( new Animal_MonkeyFish() );

And life is great...or is it?

I've recently been told that I should really try to avoid allocating memory in this fashion, because it makes memory management a chore. When I need to destroy my_vector, I have to iterate through all the elements and delete everything.

I don't think that I can store a vector of references (I might be wrong about this), so it seems like storing a vector of Animal objects is my only alternative.

When should I choose to use a vector of pointers versus a vector of objects? In general, which method is preferable? (I would like to reduce object copying as much as possible.)

Answer 1

You should use a vector of objects whenever possible; but in your case it isn't possible.

Containers of pointers let you avoid the slicing problem. But then you have to call delete on each element, like you are doing. That's annoying but possible. Unfortunately there are cases (when an exception is thrown) where you can't be sure that delete is properly called, and you end up with a memory leak.

The main solution is to use a smart pointer. Pre-C++11 comes with auto_ptr, but that cannot be used in a standard container. C++11 has std::unique_ptr and std::shared_ptr which are designed to be usable in containers (I prefer std::unique_ptr unless I really need reference counting). If you can't use C++11, the best solution is Boost smart pointers.

Answer 2

In this case, storing a vector of Animal would not work for you, as your animals have different sizes, and you wouldn't be able to store the derived objects in the spaces intended to hold the base class. (And even if they're the same size, you won't get the intended polymorphic effect, as base class methods will be executed - the virtualness of a method doesn't come into play unless you access it through a pointer or reference.)

If you want to avoid the annoyance of managing the memory yourself, you could consider storing a smart pointer such as a shared_ptr (note that auto_ptr doesn't work with STL containers, according to Max Lybbert), or some variant thereof. That way you can still use your polymorphic class, but it's a little less work for you.

There's no real hard and fast rules about when to use objects and pointers, although it's worth noting that in some cases, like yours, objects just aren't going to work for you. I tend to use objects whenever nothing precludes it though, although you do have to be concerned about expensive copy operations as you note (although sometimes they can be ameliorated by passing containers by reference).