Für dieses spezielle Szenario bin ich nicht in der Lage, die Lecks loszuwerden.
Ich erhalte die Nachricht von durchgesickerten Mock-Objekten, wenn ich den Test ausführe. Die konkrete Nachricht:
ClassElementFixture.h: 102: Fehler: Dieses Mock-Objekt (im Test ClassElementFixture.initialize verwendet) sollte gelöscht werden, ist aber nie. Seine Adresse ist @ 0x940a650.
Ich habe die Zeile markiert, auf die sich der Fehler bezieht. Hier eine vereinfachte Version meines Codes:
%Vor%Ich habe es schon gefunden Warum gibt GoogleMock mein shared_ptr aus?
bei Stack-Overflow, was verwandt ist. Aber die Vorschläge von dort beheben mein Problem nicht: X
Die einzige Möglichkeit, die ich gefunden habe, um den Fehler zumindest zu unterdrücken, ist:
%Vor%Allerdings ist das keine sehr saubere Lösung =)
Also, wie die Lecks richtig loswerden?
Wenn Sie intelligente Zeiger verwenden, müssen Sie immer noch eine klare Vorstellung von Eigentümerschaft haben, sonst können Sie schlechte Leistung, zyklische Abhängigkeiten und Speicherlecks bekommen.
Ich schlage vor, dass die Standardauswahl des intelligenten Zeigers unique_ptr für eindeutiges Eigentum sein sollte und rohe Zeiger für Beobachter verwenden soll.
Wenn die Beobachter den Besitzer überleben könnten, dann wechseln Sie zu einem shared_ptr für den Eigentümer und weak_ptr für die Beobachter.
Verwenden Sie "shared" shared_ptr nur als letztes Mittel, wenn Sie keinen eindeutigen Eigentümer haben und auf zyklische Abhängigkeiten achten.
Es ist eine alte Frage, aber ich sehe niemanden, der die Lösung erwähnt, die ich gerade gefunden habe.
Ich sah den gleichen Fehler, bis ich einen virtuellen Destruktor zu der Klasse hinzufügte, die ich verspottete. Stellen Sie in Ihrem Fall sicher, dass Sie einen virtuellen Destruktor für ParserElementFactoryMock haben. Sinnvoll, denn ohne den virtuellen Destruktor gibt das Mock-Objekt seine Ressourcen nicht frei, wenn es den Gültigkeitsbereich verlässt.
Tags und Links memory-leaks c++ shared-ptr googlemock