Polymorphism and memory leak

[eloy203]

Can anyone point me to where I can learn how to properly clean memory allocated if I have something like this:

class Mainview : public GameState
{
public:    


private:


    std::vector<GameObject*> m_gameObjects;
    
};

initiated like this:

GameObject* button1 = new Button(new LoaderParams(840, 455, 140, 40, 140, 40, "monument-B"), s_mainToMonument);

m_gameObjects.push_back(button1);

I hope I made myself clear enough...

Thanks!

[jimblumberg]

Perhaps in the class destructor?

Jim

[eloy203]

Thanks, Jim.

What I know, is that I have to declare a virtual destructor in the base class, that way, when I call delete on the polymorphic object the destructor of the derived class will be called, instead of the base's one. What I don;t know, and I'd like to learn, is how to manage this when the objects are pushed into a vector and then cleaned through a loop, like:

for (int i = 0; i < m_gameObjects.size(); i++)    {
        m_gameObjects[i]->clean();
    }

And I was wondering if someone could tell me where to study this from... (not this specific case, but to have a better understanding of the whole thing)

thanks again!

[jimblumberg]

What do you mean by "cleaned"? How is the clean() function implemented? If it is removing the items from the vector it should probably release the memory.

Jim

[eloy203]

well, that's the thing... I don't know how to implement it... I've been following a book on the SDL library, "SDL game development". and it doesn't have implementation...

[phantomotap]

O_o

You should consider containing a smart pointer instead of a raw pointer.

If you have C++11 support, you can use `std::shared_ptr<???>' component.

If you have "Boost" support, you can use `boost::shared_ptr<???>' component.

If you have "C++TR1" support, you can use `std::tr1::shared_ptr<???>' component.

If you'd rather not have the overhead of those components, you can make a simple version.

Do not use `std::auto_ptr<???>' unless you are a masochist.

Soma

[phantomotap]

well, that's the thing... I don't know how to implement it... I've been following a book on the SDL library, "SDL game development". and it doesn't have implementation...

o_O

If you don't have any guidance for the `GameObject::clean' method, you can just use the `delete' operator within your loop as long as you only store pointers obtained from the `new' operator.

Soma

[eloy203]

Thanks, Soma! that worked!

one problem though, I still have the memory leak... do you have any idea as to where to learn how to find one?

[laserlight]

What is your current code? I suggest reading Stroustrup's answer to the FAQ How do I deal with memory leaks?

[eloy203]

thanks, laserlight. I can't open the link right now. but I'll read it when I can. as for the code, what do you mean? beacouse it's pretty extensive to post...


thanks again

[Alpo]

The clean function just frees all the memory that is owned by the specific GameObject class. GameObject::clean() can be implemented differently depending on the needs of the derivative class.

Like for instance, suppose there was some derivative of Enemy named "SpecialEnemy", and SpecialEnemy has its own SDL_Texture* embedded in it (maybe as a target for special effects or something, I don't know lol). In this case the base classes of GameObject, SDLGameObject, and Enemy would not need to call SDL_DestroyTexture to free the memory, but SpecialEnemy would need to do so.

Also, keep in mind that inheritance allows you to call base class functions with the current classes variables. So if a base class like Enemy also had an owned (owning meaning the class is responsible for freeing the memory) pointer that is initialized in the derivative class, you can call the base class's clean() function in the derivative class. For an example of this, look at Enemy::draw(), which IIRC calls SDLGameObject::draw(), which as you can see uses the current (Enemy) classes variables to pass to the TextureManager class.

To know what needs cleaning, you should look at variables initialized using the 'new' keyword, and also variables that are initialized from library functions like SDL_CreateRenderer(). Also do as Phantomotap says and look into the pointer container classes, as they can take ownership of the pointer for you, freeing the memory when their destructors are called.

This site gives pretty good technical details:
std::shared_ptr - cppreference.com

Another that's less technical, but good for quick references of members, ect:
shared_ptr - C++ Reference

[eloy203]

hi, alpo! thanks... didn't your program have this problem as well?