Lernen von C++ und SDL - erzeugt das folgende ein Speicherleck?

Question

Ich lerne ein bisschen C++ selbst, und ich bin mir nicht ganz sicher, ob ich das Speichermanagement gut beherrsche. Ich kenne nur Java und ein bisschen PHP und Python, also ist das ein bisschen neu für mich. Ich arbeite auch mit SDL - es schien eine interessante Möglichkeit zu sein, den Lernprozess zu beschleunigen. Wie auch immer, ich versuche, eine Aufräumfunktion zu schreiben, die alle Oberflächen freigibt, die an einen Stapel übergeben wurden (ich benutze nur den Stapel STL). Also, ich habe den folgenden Code (kurz):

#include <stack> 

//stack of SDL_Surfaces 
stack<SDL_Surface*> surfaces; 

void clean() {  
    SDL_Surface *temp = NULL; 

    //loops through the stack depending on its size 
    while (surfaces.size() != 0) { 
     temp = surfaces.top(); 
     SDL_FreeSurface(temp); 
     surfaces.pop(); 

    } //while 
    if (surfaces.size() == 0) { 
     cout << "cleanup worked correctly" << endl;  
    } //if 
} 

//loading an image (this is in the main function) 
background = load_image("background.bmp"); 
surfaces.push(background); 

//cleaning time 
clean(); 

Ich bin nicht sicher über die Bereinigung Methode. Ich dachte, dies wäre ein besserer Weg, die SDL_FreeSurface-Funktion zu implementieren, anstatt jede Oberfläche manuell zu spezifizieren. Wenn ich also zehn Bilder auf den Bildschirm zeichne (sprich zehn Raumschiffe) und sie dann in die Luft sprenge, müsste ich sie richtig löschen. Ich würde für diese 10 Raumschiffe einen Stapel erstellen, und nach ihrer Zerstörung könnte ich sie alle vernichten, wenn das Sinn macht. Ich mache mir Sorgen, dass ich die Dinge übermäßig kompliziert habe und eine völlig neue Methode eingeführt habe, um Speicherlecks zu verursachen.

Jede Rückmeldung/Kommentar würde sehr geschätzt werden! Ich bin neu in C++ und verspotte meinen vergeblichen Versuch der Speicherverwaltung.

Answer 1

Ihr eigener Code weist keine Speicherverluste auf. Wenn man davon ausgeht, dass load_image() auch sicher ist, ist der gesamte Code von Speicherlecks sauber.

Denken Sie daran, dass kein Speicherverlust auftritt, wenn Sie den Operator new nicht verwenden.

Answer 2

Es ist ein wenig verwirrend, was Sie tun, aber, wenn SDL_FreeSurface() das Objekt (???) freigibt, dann sehe ich kein Speicherleck.

Was möchten Sie tun? Was macht SDL_FreeSurface()? Was macht load_image() und wie teilt es den Speicher zu, wenn es überhaupt funktioniert?

Answer 3

Dies scheint keine Speicherlecks zu haben. Sie möchten jedoch sicherstellen, dass Sie Oberflächen nicht zu lange herumliegen lassen oder dass es so aussieht, als hätten Sie Undichtigkeiten (dasselbe kann in Java passieren). Angenommen, dass clean oft genug aufgerufen wird, sollten Sie in Ordnung sein.

Dies verschiebt das Problem der Reinigung der einzelnen Oberflächen (durch den Aufruf SDL_FreeSurface zur entsprechenden Zeit) auf den Stapel der Oberflächen zu reinigen (durch den Anruf clean zur entsprechenden Zeit). Wenn Sie bereits Code (oder eine Idee) zum Verwalten des Stapels haben, würde ich weitermachen und damit laufen. Wenn nicht, würde ich versuchen, die Oberflächenlebensdauern individuell zu verwalten, da dieser Ansatz flexibler ist und kein neues Konzept einführt.

Answer 4

Lesen Sie mehr über RAII - C++ ist sehr gut darin. Sobald Sie verstehen, was passiert (im Grunde ist es Ressourcenzuweisung im Konstruktor und Aufhebung der Zuordnung im Destruktor - was bedeutet, dass Ihre Objekte sich selbst bereinigen) - können Sie nette Wrapper für die SDL-Funktionen erstellen. Hier ist, wie man eine Oberfläche tun würde:

CBitmapSurface::CBitmapSurface(const std::string &filename) 
{ 
    m_pSurface = SDL_LoadBMP(filename.c_str()); 
} 

CBitmapSurface::~CBitmapSurface() 
{ 
    SDL_FreeSurface(m_pSurface); 
} 

wo m_pSurface ist eine Membervariable vom Typ SDL_Surface *.

In der perfekten Welt möchten Sie diese Klasse nicht kopierbar machen, behandeln Sie den Move-Konstruktor, wenn Sie C++ 0x verwenden und Fehlercodes überprüfen und Ausnahmen auslösen. Aber das sollte dich beginnen.

Answer 5

der beste weg bei der Suche nach Speicherlecks ist Verwendung Valgrind. Soweit ich weiß, funktioniert es nur auf Linux, aber es lohnt sich die Zeit zu untersuchen und zu verwenden.