Avoid memory leak in C++ class - c++

Question

I've defined a C++ class with the following header file:
class EarleyParser
{
public:
EarleyParser();
virtual ~EarleyParser();
void initialize( string filePath, bool probabilityParse );
private:
bool probabilityParser;
typedef unordered_map< string, list<Production>* > productionHashTable;
productionHashTable earlyHashTable;
};
As you can see a member element of the class is an unordered_map whose key element is a string and content element is a pointer to a list of objects of another class named Production (don't mind it, it could be anything).
My question is if I should leave it to the default destructor to free memory allocated, or if I should manually inspect the hash table and delete all of its elements.
In the second case what would be the procedure? Calling this for each element will be ok?
EarleyParser::productionHashTable::const_iterator got = this->earlyHashTable.find( "key" );
delete[] got->second;

Answer 1

You need to clarify who owns the list<Production> objects owned by EarlyParser. If EarlyParser owns them, then you need to free the resources. You can do it by iterating over the list and calling delete on each dereferenced iterator (not delete[]). Or you can store unique_ptr<list<Production>> instead. On the other hand, the simplest solution is to store list<Production> unless you really have very strong reasons for storing pointers.

Answer 2

If you're going to store pointers to anything in your map, you'll have to manually go through the map and delete each one. Normally in a class you'd stick to RAII (Resource Acquisition is Initialization) and construct things in the constructor and destroy in the destructor
for (;;)
delete map->second; //it's not an array of lists
However a pointer to a container is NOT a good idea. Why do you do need a pointer? What problem are you trying to solve using a pointer to a list?
Using a smart pointer like std::unique_ptr is a much better idea than raw pointers. Raw pointers should be a last resort, not the first thing you grab when you can't think of anything better.

Answer 3

Use a:
typedef unordered_map< string, std::unique_ptr<list<Production> > > productionHashTable;
instead. Then you don't need to worry about managing memory.

Answer 4

The compiler synthesized destructor is not going to delete dynamically allocated lists you put in your map, so you have to do it yourself. In this case you can just iterate through your map and delete the second member of each element:
EarleyParser::~EarleyParser() {
for ( productionHashTable::iterator i = earlyHashTable.begin(); i != earlyHashTable.end(); ++i )
delete i->second;
}
A better approach would be to put lists in your map rather than pointers to lists. In that case the compiler would automatically take care of destruction, as in:
typedef unordered_map< string, list<Production> > productionHashTable;

Answer 5

Unordered_map's destructor actually calls the destructors of the object it has, which means that the destructor's of the lists will be called.
The destructor of std::list has this note:
Note, that if the elements are pointers, the pointed-to objects are not destroyed.
So this means, you will have to clear that memory yourself. Yes, going through the container and deleting elements 1by1 is fine. As other answerers mentioned, holding pointers like this is not a good idea though.

Answer 6

Since you're using a raw pointer to the std::list you'll have to delete it yourself either during the lifecycle of the map or when you clean up the EarleyParser object in its destructor.
You could use something like this in your destructor:
for ( auto it = productionHashTable.begin();
it != productionHashTable.end(); ++it )
{
delete it->second;
}
productionHashTable.clear()
Note that the last line isn't strictly necessary as it will be cleared anyway as the EarleyParser object is destructed but clearly you mustn't use the values in the map after you've deleted them!