Question

What potential memory leaks won’t an implicit destructor handle? I know that if you have anything stored on the heap it won’t handle it, and if you have a connection to a file or a database, that needs to be handled manually. Is there anything else? What about, say, non-base data types like vectors?

Also, in an explicit destructor, need you destroy non-heap variables which would have been destroyed by the implicit, or are they handled automatically?

Thanks

Answer 1

What potential memory leaks won’t an implicit destructor handle? I know that if you have anything stored on the heap it won’t handle it, and if you have a connection to a file or a database, that needs to be handled manually. Is there anything else? What about, say, non-base data types like vectors?

To put it simply, you are correct. The only thing not handled by the implicit destructor is memory allocated in the form of a pointer or another type of resource that needs to be released explicitly.

With regard to vectors or any other class type objects; all classes have a destructor which takes care of releasing their data. The destructor of an object of this type is called when it goes out of scope. All basic data types like: int, float, double, short, bool etc are released in similar fashion.

Also, in an explicit destructor, need you destroy non-heap variables which would have been destroyed by the implicit, or are they handled automatically?

The answer to this is that they are handled automatically, in fact you should never ever try to explicitly call the destructor of an object.

In an implicit destructor the following occurs:

• Each of the member variables of the class have their destructors called in turn.

In an explicit destructor the following occurs:

• The body of the explicit destructor is executed
• Each of the member variables of the class have their destructors called in turn.

So you can see that an explicit destructor is much the same as an implicit one, except that you can take any necessary manual intervention.

Now as a bit of advice with regard to managing memory allocated objects you should pretty much always use RAII (resource acquisition is initialisation). The crux of this is smart pointers, these are pointers that are deleted correctly when they go out of scope just like non heap allocated objects. Ownership becomes an issue once you start using them but that’s a story for another day. A good place to start with smart pointers is boost::shared_ptr. (btw if you haven’t got on board with boost yet and you write c++ code do yourself a favour…)