Destructor gets called when I don't want it to

Question

The destructor of the class I made gets called before the end of scope. I think that it has something to do with the reallocation in the vector when I add another element to it. How to I surpass this issue? I want the destructor to be called only when the object reaches the end of scope in my code.

#include <string>
#include <iostream>
#include <vector>

using namespace std;

class A
{
public:
    ~A() { cout << "destructor called\n"; }
};

int main ()
{
    A one, two;

    vector<A> vec;
    cout << "push_back one" << endl;
    vec.push_back(one);
    cout << "push_back two" << endl;
    vec.push_back(two);
    //destructor gets called here
    system("pause");
    return 0;
} //while i want it to be called here

You have to call [`reserve()`](http://en.cppreference.com/w/cpp/container/vector/reserve). — David G, Dec 11 '14 at 19:42
I'm looking for a different workaround. Calling reserve() sounds like a cheat to me. I want to fully understand the issue. Maybe making class A "smarter" by adding some code to it? — McLovin, Dec 11 '14 at 19:45
Not related to your problem, but [`using namespace std;`](http://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice) and [`system("pause");`](http://stackoverflow.com/questions/1107705/systempause-why-is-it-wrong) are two of my pet peeves. — Fred Larson, Dec 11 '14 at 19:47
If the vector runs out of space in its buffer and needs to allocate a new one, the contents of the old buffer have to be destroyed. There's no way around this. — dlf, Dec 11 '14 at 19:47
It's no cheat. This is normal behavior of `std::vector`. It's growing when you `push_back`, causing reallocation and copy/destruction of `A` objects. `reserve()` just lets `std::vector` know in advance how many objects it will need to store. — Fred Larson, Dec 11 '14 at 19:49
I don't know that this is "better" from a design perspective, but if you used a vector of A *pointers* (or smart pointers), then it would be the pointers instead of the As that would be destroyed during a resize. — dlf, Dec 11 '14 at 19:51
@Pilpel Why is this an "issue"? If you explain why the invocation of the destructor is a problem, we can probably help you figure out the appropriate fix. You should probably not have a vector of objects if the destructor of that object does something significant. — David Schwartz, Dec 11 '14 at 20:06

score 3 · Answer 1 · answered Dec 11 '14 at 19:49

Printouts in your code do not show you the complete picture: the destructor is called for a different object.

Take a look at this modified code. I added printouts of the address, and logging in some other key places, such as calls of the assignment operator and copy constructor.

#include <string>
#include <iostream>
#include <vector>

using namespace std;

class A
{
public:
    A() {cout << "constructed " << (void*)this << "\n";}
    A(const A& a) {cout << "copied " << (void*)(&a) << " to " << (void*)this << "\n"; }
    A& operator =(const A& a) {cout << "assigned " << (void*)(&a) << " to " << (void*)this << "\n"; }
    ~A() { cout << "destructor called for " << (void*)this << "\n"; }
};

int main ()
{
    A one, two;

    vector<A> vec;
    cout << "push_back one" << endl;
    vec.push_back(one);
    cout << "push_back two" << endl;
    vec.push_back(two);
    //destructor gets called here
    return 0;
}

It produces the following output (demo):

constructed 0xbff229b2
constructed 0xbff229b3
push_back one
copied 0xbff229b2 to 0x970c008
push_back two
copied 0xbff229b3 to 0x970c019
copied 0x970c008 to 0x970c018
destructor called for 0x970c008
destructor called for 0x970c018
destructor called for 0x970c019
destructor called for 0xbff229b3
destructor called for 0xbff229b2

You can see that objects one and two (0xbff229b2 and 0xbff229b3) do not get destroyed until the end, when they go out of scope. Its their copies that get destroyed when the vector is resized.

Is there a way to know when only the original objects get destroyed? — McLovin, Dec 11 '14 at 20:37
@Pilpel Not exactly - when it comes to calling destructors, there is no difference to C++ between objects created on the stack and copied objects. One way to get close to that would be to store a flag in the object that would signal to the destructor that it's an "original" object, and to not copy that flag in copy constructors or assignment operators. — Sergey Kalinichenko, Dec 11 '14 at 20:42

Julian · Answer 2 · 2014-12-11T21:12:29.880

According to the C++ Standard § 23.3.6:

Vectors have a specific capacity, meaning

The total number of elements that the vector can hold without requiring reallocation

When you push_back an additional element, this effectively increases the container size by one, which

Causes reallocation if the new size is greater than the old capacity

Re-allocation implies that you are de-allocating (i.e. destroying) the elements in the vector, then allocating (i.e. constructing) them again.

Note that, in your case, the original one and two instances of A are not destroyed, rather their copies which are stored in the vector are.

A programmer needs to be more careful with references and iterators though, because

Reallocation invalidates all the references, pointers, and iterators referring to the elements in the sequence.

As others have mentioned, reserve() will help prevent this, because

No reallocation shall take place during insertions that happen after a call to reserve() until the time when an insertion would make the size of the vector greater than the value of capacity().

justin · Answer 3 · 2014-12-11T19:58:51.033

As the comments suggest, you should use std::vector<>::reserve(size_t).

What you are seeing is implementation defined. Most implementations approximately double the reserved allocation size when growing. This is to avoid making many allocations and copies whenever the size grows.

Reserving simply suggests to the collection that you will need n elements. The implementation, if it chooses to honor the request, reallocates and moves/copies the existing values to the new allocation which is large enough to hold the number of elements you've requested. Now you can push back without costly reallocation. Reserving properly can save you many reallocations as the container is resized, when you have a good idea what the final size will be.

Reserving in this case would avoid that resize, and the destruction of the temporary you see.

You see the destructor likely because the collection is resizing. As you push back the second time, it reallocates.

If the object must never be destroyed, you should consider another collection type or storage location, since the program in its present form relies on implementation-defined behavior (i.e. the standard's specification for vector does not make the guarantee you would need).

Destructor gets called when I don't want it to

3 Answers3