High Levels of Class Inheritance and Memory Leaks

[JayhawkZombie]

Hey, all. As we all know, I'm one of the newbies around here. I help where I can. I know I've made mistakes, and thank you for correcting them when I make them. I'm still learning, so forgive my mistakes if you can.

Now, I'm not going to give you my class structure code. That would be terrible.
You don't need to look through that.
What I want is to make sure I'm deleting everything I create.

I have a "manager" class that accepts a pointer to a dynamically allocated "supervisor" object and stores the pointer. The "supervisor" class takes a pointer to a "worker" class and stores a pointer to it. It can take an arbitrary number of these pointers and stores them in a vector.

The "worker" pointer it stores is of a base class type, but the object it is pointing could be an arbitrarily complex derivation of that base class.

Now, I know about the virtual destructor. I can verify that destruction is going down the inheritance levels, and all the correct destructors are called.

I.e. If my "worker" has 4 levels of inheritance, it calls deltructor 4, then destructor 3, then 2, then 1.

Constructors earlier in the list may allocate something IT needs, but not something the one below it needs. What I want to make sure is that those things are being deleted.

In the destructor of the "final" level of inheritance, I should only delete whatever I allocated in that level, right? The destructors lower down the levels would delete whatever was allocated in those levels? It's been a while since I've dealt with inheritance like this and certainly a while since I've done dynamic allocation at different levels of inheritance.

"Manager" calls 'get ready' on the supervisor, which calls 'get ready' on the workers. Then "Manager" calls 'delete' on supervisor, which calls 'delete' on all the workers. You don't call 'delete' on the supervisor main. That will make the controller unable to delete it and cause a crash (it'll be deleted before "Manager" deletes it because "Manager" isn't deleted until the program terminates).

I think I've got my deletion going properly.
I can't use Visual Studio's memory leak detector. It will give me a false positive, because cleanup isn't done until the program completely terminates, and there's no way to call _CrtMemoryDump() after my frame stack for 'main' has been destroyed.

[cire]

The short answer is: Don't use manual memory management.

Use containers of objects and/or smart pointers.

Googling RAII may be useful.

[JayhawkZombie]

I see. I've learned of RAII in my software engineering class.

I'd love to not have to refactor all of my code, but this gets more complex the more levels of inheritance I have.

I could refactor, since my program logic would be the same., but it would take a decent amount of time. Could you maybe elaborate on how I might use smart pointers? Right now, when I add a "worker" to the "supervisor", I send a raw pointer to that worker. How would that interface change when using smart pointers?

[ne555]

> I can't use Visual Studio's memory leak detector.
¿what about valgrind?


> because cleanup isn't done until the program completely terminates
¿you have globals?


> I'm not going to give you my class structure code. That would be terrible.
¿you know what's terrible?

"Manager" calls 'get ready' on the supervisor, which calls 'get ready' on the workers.(...)

code would be more clear than your description.


> I send a raw pointer to that worker. How would that interface change when
> using smart pointers?
send a smart pointer

[dhayden]

Manual memory management isn't hard, you just have to be clear in your head and in the code about who owns the pointer. The owner is the one who deletes it. If class A has a pointer to a class B instance and A owns the pointer then:
- ~A deletes the pointer.
- A's copy constructor and assignment operator make a copy of the B instance (or they are made illegal).