when do i dynamicaly allocate my variables/array

[Eric]

i'm still new to c++ but i've been reading about it :-)

in the simple example when i run the sfml template fromxcode it creates a sound, a background image and a text in the upper right corner
sf:texture texture allocate a place for my texture?
but it is not dynamically - meaning i can't free the memory? Right?
If i want to do level1 and level 2 everything  concerning level 1 should be dynamicaly allocated so that i can free the memory for level2 - right?

I've always had a garbage collector to clean my programs, so I have to ask these simple questions :-)

Thanks a lot for your help. I can't wait to write 'yet-another-space-invaders' using SFML.
Regards Eric

[zsbzsb]

Memory can be freed no matter how it is allocated. The advantage to not using new/delete statements is that you do not need to worry about freeing memory. I highly recommend that you stop using new/delete statements. RAII will make your code much cleaner and easier to understand.

[Eric]

would this be the correct way to use c++/sfml in order to avoid memory leaks?:

 // Load a sprite to display
    sf::Texture texture;
    if (!texture.loadFromFile(resourcePath() + "cute_image.jpg")) {
        return EXIT_FAILURE;
    }
    sf::Sprite sprite(texture);

    //use my sprite in the game...
   
    sprite.~Sprite();
    texture.~Texture();

[Raphman]

Since you're not using the new keyword anywhere (which you would only use with pointers anyway), the sprite and texture variables will destroy themselves once they go out of scope. You don't need to manually call the destructors like that. Unless you want to destroy them early, but I personally can't think of a reason for that.

The code you have there should be fine minus the destructor calls at the end.

[eXpl0it3r]

would this be the correct way to use c++/sfml in order to avoid memory leaks?:

    sprite.~Sprite();
    texture.~Texture();
 

You don't need to manually call the destructors like that.

In fact, you should never manually call the destructor, since it's not defined and thus can lead to undefined behavior, which in turn could magically work, it could lead to strange issues, well strictly speaking anything could happen.

You can learn a lot on RAII on the internet, just search a bit for it.

[Raphman]

Oh, I was unaware that the destructors are undefined( I never looked for them because I never needed them)

Yes, in that case it'd be dangerous to use. Don't use 'em at all Eric!

[eXpl0it3r]

Oh, I was unaware that the destructors are undefined( I never looked for them because I never needed them)

The destructors itself are not undefined, but you run into undefined behavior when you manually call the destructor.

[Raphman]

Now that's something I didn't know. Maybe I missed that lecture in C++I hah. although I never actually called a destructor manually, because why would I? =P

[binary1248]

In fact, you should never manually call the destructor, since it's not defined and thus can lead to undefined behavior, which in turn could magically work, it could lead to strange issues, well strictly speaking anything could happen.

Never say never . I am pretty sure if the C++ standardization committee saw explicit destructor calls as something that should never be done, they would just make it illegal in the language specification. Since it isn't, you have to ask yourself, which C++ archwizard could think of such a good reason to make it legal that they allowed it.

The answer is: placement new and "placement delete".

Note that this is something I have also tried, and if you know how to use it properly, it can be quite useful. For beginners though, just pretend that what eXpl0it3r said is 100% true and think about it in another 4 years .

[eXpl0it3r]

Never say never . I am pretty sure if the C++ standardization committee saw explicit destructor calls as something that should never be done, they would just make it illegal in the language specification. Since it isn't, you have to ask yourself, which C++ archwizard could think of such a good reason to make it legal that they allowed it.

For beginners though, just pretend that what eXpl0it3r said is 100% true and think about it in another 4 years .

I'm well aware.

[MorleyDev]

It'd be required for things like creating your own memory manager. Then you have to manually call constructor and destructor, but it's reasonable to say unless you're a hardcore embedded programmer counting the individual CPU cycles and bytes of RAM used, you will never be in a situation where they have to do that as part of a serious project