Recently I got bit by void* again because of another C++ quirk I didn’t think through. I had a class which wrapped a void* which could be one of many different structs. The structs were POD and didn’t have any shared functionality hence I didn’t bother creating an inheritance hierarchy. Unfortunately I defined the structs like so
class C1 {
struct S1 {
int field1;
float field2;
};
struct S2 {
char field1;
};
~C1() {
delete m_pData;
}
void* m_pData; // Can be S1,S2,etc ...
}
Unfortunately this appeared to work fine for quite some time. Then after a couple of days of bug fixes I ended up with a memory leak which I quickly tracked down to a leaked COM object. Although C1 was at fault I didn’t suspect any changes to this class because after all it was working fine for some time and all I did was add a new field to one of the structs. If the structs were being successfully free’d before a new field shouldn’t change anything.
The field I added was of type CComPtr
Why did this happen’ By deleting a void* and expecting a destructor to run what I’m really doing is asking C++ to behave polymorphicly. C++ as a rule won’t behave this way unless it is specifically asked to with inheritance and virtual.’? In the case of void*, it just won’t. The fix is to actually implement an inheritance hierarchy which supports polymorphism.
It’s just another rule that I need to remember when coding C++.
Deleting void* is dangerous, period.
Unfortunately C++ has too many of these rules and not enough enforcement.