Memory Leaks - mit VS.net?
-
operator void schrieb:
Das geht nicht, weil du in der zweiten Zeile (ctemp soll wohl auch ptr_chartemp sein?) den Zeiger vom allokierten Speicher auf ein Stringliteral umbiegst. Schon danach kannst du den Speicher nicht mehr freigeben. Wenn du "bar" mit strcpy in *ptr_chartemp kopieren würdest, könnte der Aufrufer der Funktion den Speicher über delete[] freigeben und alles wäre gut. Allerdings wird der Code dann schnell sehr zerbrechlich
Wenn du eine Funktion allokierten Speicher zurückgeben lassen willst, geht das normalerweise am besten mit std::auto_ptr, der genau für sowas gebaut wurde. Allerdings kann man diesen hier nicht verwenden, weil der Speicher mit delete[] und nicht mit delete freigegeben werden muss.jo, sollte ptr_chartemp heissen. Haben jetzt doch mehr std::strings eingebaut und die Leaks sind weg std::auto_ptr muss ich mir nochmal anschauen. Will aber versuchen weg von den Pointern und mehr mit Objekte und Referenzen auf diese arbeiten. Was nur seltsam an der Fkt _CrtDumpMemoryLeak() ist, dass sie auch noch gültigen (referenzierten) Speicher dumped:
// gehört zum Code weiter unten { TestKlasse* pTestobjekt = new TestKlasse("foo"); _CrtDumpMemoryLeaks(); // liefert den Leak } _CrtDumpMemoryLeaks(); // alles ok, da der dtor aufgeräumt hat
Er zeigt also allen dynamischen Speicher an - gibts vielleicht irgendeine Debuggoption oder (_Crt-)Funktion, mit der ich an jeder Stelle des Codes gucken kann, ob noch alles klar mit meinem Speicher ist (-> unreferenzierten Bereich)? So kann ich die _CrtDumpMemoryLeaks() nur am Ende und außerhalb des Gültigkeitsbereiches verwenden...
ps: was hat es eigentlich mit dem foo & bar immer auf sich?
Gibts da einen Hintergrund?
-
Optimizer schrieb:
Ich würde nicht innerhalb einer Funktion Speicher anfordern und dann außerhalb ihn wieder freigeben
Stimmt, sollte man vermeiden ausser es ist wirklich so gewollt (also bei speziellen Alloc-Funktionen etc.).