Question

This may well be a really silly/basic question, but I can’t really figure it out. I’ll tell you what I think – please correct me if/where I’m wrong.

When we’re using STL containers to store raw pointers, we have to take care of cleaning up after them:

std::list<animal*> alist;
animal *a = new animal();
alist.push_back(a);
...
animal *b = alist.front();
alist.pop_front();
//do stuff with b
delete b;

What happens if we store objects? It is my understanding that if a container full of objects goes out of scope, all the objects inside it are destroyed. Correct?

But what if we remove an object from a container, using std::list<T>.pop_front() for example?

std::list<animal> alist;
{
  animal ani();
  //ani is inserted at the end of the list (it IS ani rather than a copy 
  //since push_back accepts const T&)
  alist.push_back(ani);
} //nothing is deallocated/destroyed here
...
{
  animal b = alist.front(); //b is now a copy(?!) of the front element
                            //created via copy constructor
  alist.pop_front(); //the front element of the list is 
                     //destroyed/destructor is called 
  //do stuff with b
} //b goes out of scope

Answer 1

When you store something in a container, whatever you pass is copied into the container¹. You still own the original object²; the container owns its copy of the object. It’s true that push_back (for one example) takes its parameter by reference. This means when you pass your object to be pushed into the container, no copy is needed for use as the parameter itself, but what’s put into the container is still a copy of what you told it to push. Passing by reference means only one copy is needed; if it was passed by value, (at least in C++98/03) that would have resulted in two copies: one copy from your object to the function argument, then another copy from the function argument into the container. Passing by reference allows a single copy directly from your original object directly into the container.

Likewise, when you get an object from the container, you’re getting a copy of what was in the container. The container still has its object, and you have your object. Each of these has its own lifetime.

When you erase or pop an object from a container, that object is removed from the container and destroyed — if it’s something that has a destructor, the destructor will be called to destroy it.

The objects in a container will be destroyed when the container itself is destroyed. Your object will be destroyed whenever it happens to be — the fact that it came from a container has no effect on that. If it’s a local variable, it’ll be destroyed when it goes out of scope. If it’s a global, it’ll last ’til the end of time (for the program). If you return it from a function and that’s used to initialize a reference, the normal rule for extending its lifetime there will be observed. Bottom line: at that point, it’s just another object, that’ll have a lifetime just like any other object defined in the same way.

This can get a little…fuzzy when/if you store pointers (raw or smart) in a container. All of the above actually remains true, but the object being copied/stored is a pointer. Unless you use some container that’s “aware” that you’re storing pointers (e.g., Boost ptr_vector) it’s just dealing with a pointer, and “ignoring” the fact that somewhere out there is an object that the pointer refers to.

---

1. In C++11, you can use, for example, emplace_back to construct an object in place in the container, but the same basic idea applies — the container has an object that it owns, and you never touch directly.
2. Here I’m using “object” more like a non-programmer would — just to mean “some thing”, not necessarily an instance of a class. It may not even be an “object” in the sense that C uses the word — it could be a pure rvalue (e.g., push_back(10)).