C++ STL: should I store entire objects, or pointers to objects?

Question

Designing a new system from scratch. I'll be using the STL to store lists and maps of certain long-live objects.

Question: Should I ensure my objects have copy constructors and store copies of objects within my STL containers, or is it generally better to manage the life & scope myself and just store the pointers to those objects in my STL containers?

I realize this is somewhat short on details, but I'm looking for the "theoretical" better answer if it exists, since I know both of these solutions are possible.

Two very obvious disadvantage to playing with pointers: 1) I must manage allocation/deallocation of these objects myself in a scope beyond the STL. 2) I cannot create a temp object on the stack and add it to my containers.

Is there anything else I'm missing?

Answer 1

If you're storing polymporhic objects you always need to use a collection of base class pointers.

That is if you plan on storing different derived types in your collection you must store pointers or get eaten by the slicing deamon.

Answer 2

You seem to have a good grasp of the difference. If the objects are small and easy to copy, then by all means store them.

If not, I would think about storing smart pointers (not auto_ptr, a ref counting smart pointer) to ones you allocate on the heap. Obviously, if you opt for smart pointers, then you can't store temp stack allocated objects (as you have said).

@Torbjörn makes a good point about slicing.

Answer 3

Using pointers will be more efficient since the containers will be only copying pointers around instead of full objects.

There's some useful information here about STL containers and smart pointers:

http://stackoverflow.com/questions/111478/why-is-it-wrong-to-use-stdautoptr-with-stl-containers#111511

Answer 4

Why not get the best of both worlds: do a container of smart pointers (such as boost::shared_ptr). You don't have to manage the memory, and you don't have to deal with large copy operations.

Answer 5

Generally storing the objects directly in the STL container is best as it is simplest, most efficient, and is easiest for using the object.

If your object itself has non-copyable syntax or is an abstract base type you will need to store pointers (easiest is to use shared_ptr)

Answer 6

Since people are chiming in on the efficency of using pointers.

If you're considering using a std::vector and if updates are few and you often iterate over your collection and it's a non polymorphic type storing object "copies" will be more efficent since you'll get better locality of reference.

Otoh, if updates are common storing pointers will save the copy/relocation costs.

Answer 7

This really depends upon your situation.

If your objects are small, and doing a copy of the object is lightweight, then storing the data inside an stl container is straightforward and easier to manage in my opinion because you don't have to worry about lifetime management.

If you objects are large, and having a default constructor doesn't make sense, or copies of objects are expensive, then storing with pointers is probably the way to go.

If you decide to use pointers to objects, take a look at the Boost Pointer Container Library. This boost library wraps all the STL containers for use with dynamically allocated objects.

Each pointer container (for example ptr_vector) takes ownership of an object when it is added to the container, and manages the lifetime of those objects for you. You also access all the elements in a ptr_ container by reference. This lets you do things like

class BigExpensive { ... }

// create a pointer vector
ptr_vector<BigExpensive> bigVector;
bigVector.push_back( new BigExpensive( "Lexus", 57700 ) );
bigVector.push_back( new BigExpensive( "House", 15000000 );

// get a reference to the first element
MyClass& expensiveItem = bigList[0];
expensiveItem.sell();

These classes wrap the STL containers and work with all of the STL algorithms, which is really handy.

There are also facilities for transferring ownership of a pointer in the container to the caller (via the release function in most of the containers).

Answer 8

If the objects are to be referred to elsewhere in the code, store in a vector of boost::shared_ptr. This ensures that pointers to the object will remain valid if you resize the vector.

Ie:

std::vector<boost::shared_ptr<protocol> > protocols;
...
connection c(protocols[0].get()); // pointer to protocol stays valid even if resized

If noone else stores pointers to the objects, or the list doesn't grow and shrink, just store as plain-old objects:

std::vector<protocol> protocols;
connection c(protocols[0]); // value-semantics, takes a copy of the protocol