Memory leak

[kimerafusion]

Hey there, got a problem in some code, I saw that I had a mem leak (using Task Manager), and when I started looking everywhere by commenting 99% of my code I saw that the mem leak was supposed to be in this part of code :

void RectGrid::DrawGrid(sf::RenderWindow *window) {
        sf::Sprite RectSprite = *new sf::Sprite();
        RectSprite.setTexture(*RectTexture);
        for (int x = 0; x < grid.size(); x++) {
                for (int y = 0; y < grid.at(x).size(); y++) {
                        window->draw(RectSprite);
                }
        }
}

RectTexture is nothing more than an sf::Texture* and grid is an std::vector<std::vector<RectType>> where RectTypeis an enum. window is a pointer on an sf::RenderWindow.
I really don't understand what I have done wrong in this code...

[math1992]

When do you delete RectSprite? Also if you want to create a tile map (Or anything with a grid) use sf::VertexArray instead.

[FRex]

When do you delete RectSprite?

Never, just as he should. You do not delete autos.

 sf::Sprite RectSprite = *new sf::Sprite();

On this line, you create a new sprite, dynamically on the heap, then copy it into a local variable and then discard it, that discarded sprite is the leak. RectSprite like that itself is fine, it gets freed automatically. What is wrong is the = *new sf::Sprite() why do you do that?

[eXpl0it3r]

If you play around with raw pointers and new/delete while barely understanding the concept it's only a question of when you'll write leaking code.
Use references whenever possible, don't do manual memory management and learn about RAII.

Also if you "somewhere" read this kind of code, I strongly advise you to drop that source, it will teach you more bad things than good things. If you're interested in a good C++ book to get  a solid base, check out this list.

Also the task manager is not a good or not a way at all to track memory leaks.

[kimerafusion]

Oh thanks a lot, that's why. Yeah, probably something I did not understand properly while learning C++.

[Mörkö]

What about this?

#include <SFML/Graphics/Texture.hpp>
int main() {
        sf::Texture texture;
}

==6844== HEAP SUMMARY:
==6844==     in use at exit: 15,082 bytes in 68 blocks
==6844==   total heap usage: 5,418 allocs, 5,350 frees, 4,658,922 bytes allocated
==6844==
==6844== Searching for pointers to 68 not-freed blocks
==6844== Checked 2,635,864 bytes
==6844==
==6844== LEAK SUMMARY:
==6844==    definitely lost: 0 bytes in 0 blocks
==6844==    indirectly lost: 0 bytes in 0 blocks
==6844==      possibly lost: 0 bytes in 0 blocks
==6844==    still reachable: 15,082 bytes in 68 blocks
==6844==         suppressed: 0 bytes in 0 blocks
==6844== Reachable blocks (those to which a pointer was found) are not shown.
==6844== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==6844==
==6844== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
--6844--
--6844-- used_suppression:      2 glibc-2.5.x-on-SUSE-10.2-(PPC)-2a /usr/lib64/valgrind/default.supp:1286
==6844==
==6844== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

I don't understand all the technical info that comes before that part, but as far as I know it should be concluding this:

All heap blocks were freed -- no leaks are possible

[binary1248]

In that case, you should probably run valgrind with --leak-check=full --show-leak-kinds=all and show us where the leaked blocks come from.