-
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...
-
When do you delete RectSprite? Also if you want to create a tile map (Or anything with a grid) use sf::VertexArray instead.
-
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?
-
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 (http://www.bromeon.ch/articles/raii.html).
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 (https://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list).
Also the task manager is not a good or not a way at all to track memory leaks.
-
Oh thanks a lot, that's why. Yeah, probably something I did not understand properly while learning C++.
-
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
-
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.