SFML and Memory Management

[toitus]

I'm curious how people are handling memory management in SFML2.

Right now, I have no idea how memory of sf::Font, Texture, etc, are handled, or supposed to be
handled, in SFML2.

If anyone has any good resources for learning on this subject, please let me know.

[Jesper Juhl]

SFML is not really any different from any other C++ library in this regard.
You need to keep track of object lifetimes (of course) to ensure that objects live as long as they need to, but that should not be a surprise.
When you do need to dynamically allocate memory you should follow the RAII idiom and always make sure that newly allocated memory are assigned directly to a smart pointer or other object that will handle its destruction in all apropriate cases. Again, this should be no surprise since it's just good C++ practice.

Could you be a bit more specific about what you have questions about? Are there any specific parts of SFML that worry you? And specifically what worries you.
Just saying you are not sure about "sf::Font, Texture, etc" doesn't really give much to go on. Of course a sf::Font needs to live at least as long as any sf::Text is using it and a sf::Texture needs to outlive any sf::Sprites that use it. But that can't be what your question is about since that's pretty obvious.
So what exactely is worrying you?

[toitus]

Edit: Sorry about the lack of specificity here, looking back I realize it's really hard to help
someone if they aren't specific about their issues.

To be a little more specific, I'm experimenting with state management.
At the moment, I'm using a stack (std::vector) of state pointers.

So, I push state objects created with the new keyword when I want to change state
and then I attempt to delete the previous state pointer and remove it from the stack.

I'm not using smart pointers.

I've tested this same method in SDL but SDL's clean up functions are very clear which makes it
easy to clean up.

I'm only testing with two states. One state has a RenderTexture and a couple Textures, the other has no Textures at all.

What happens is when I repeatedly switch between states, memory usage increases by ~2mb per switch.

I guess I'm mostly curious how to handle clean up in SFML2.

Edit: I really like clean up in SDL, it's very straight forward, but SFML offers a lot of nice features and I think I would prefer it over SDL if I can figure out how to manage my resources correctly.

Thanks for the response also =P
I'm reading your RAII link right now, that may fix my issues.

[Jesper Juhl]

I'm not using smart pointers.

Why on earth not???

I've tested this same method in SDL but SDL's clean up functions are very clear which makes it
easy to clean up.

This doesn't help anything. SFML is not SDL and besides you don't tell us anything about how cleanup is different in any useful details.

I'm only testing with two states. One state has a RenderTexture and a couple Textures, the other has no Textures at all.

What happens is when I repeatedly switch between states, memory usage increases by ~2mb per switch.

So obviously you are allocating memory on state change and you don't clean out old objects. Why you don't use smart pointers and get rid of your headaches I don't understand... But, Could you show us a complete and minimal example? Otherwise it's a bit hard to tell what's causing the problem (also please read this).

I must be missing something, I think.

Yes. Probably RAII and smart pointers.

[toitus]

Well, I know for sure that the problem is that I'm allocating and not cleaning properly.

I read that, in SFML, resources are freed when they go out of scope and that there are
no functions I can call to free resources for me. So, is this the reason I should be using RAII
and smart pointers (other than the fact that it's good c++ practice)? If so, I'll do a bit more research on the subject and adjust accordingly.
 

[Jesper Juhl]

There is nothing SFML specific here (as I see it).
If you dynamically allocate memory and don't assign it directly to a smart pointer (or other owning class), then you have 100% responsabillity for cleaning up (delete or delete[]) that memory - and if you don't do that whenever needed (which can be quite complex to figure out) then you can leak. Period.  Knowing all the places where your object can go out of scope become unreferenced etc is difficult (and if you want to handle them all manually your code often becomes a mess) which is exactely why you should embrace the RAII idiom (and smart pointers help you do that).

Edit: This applies to all C++ code btw - not just SFML.

[toitus]

Alright, this makes sense. I will do some research on RAII and smart pointers and continue
testing.

I appreciate the suggestions and thanks for the help.