dynamische Arrays
-
also ich lerne gerade c++ und in meinem komischen buch steht nicht was waere wenn ich eine dynamische variable nciht löschen (speicher wieder freigeben) würde.
Wo und wie lange würde die bleiben?
-
Bis zum Programmende [in früheren Betriebssystemen sogar teilweise noch über das Programmende hinaus]
Besonders fatal: wenn die Funktion, die solchen Speicher allokiert, oft und mehrfach aufgerufen wird, stirbt Dein Programm irgendwann an Speichermangel.
-
danke
-
...dabei entstehen sogenannte speicherlöcher, weil der compiler sich immer mehr speicher aus dem heap holt ihn aber nicht mehr freigibt.
zusätzlich zum delet arrayname[];
empfiehlt es sich immer nochmal den pointer auf NULL zu setzten falls einmal was mit der freigabe nicht funktioniert hat, nicht unbedingt nötig, aber in einem schönen programmierstil recht sinvoll
-
Original erstellt von <VesaMan>:
empfiehlt es sich immer nochmal den pointer auf NULL zu setzten falls einmal was mit der freigabe nicht funktioniert hat, nicht unbedingt nötig, aber in einem schönen programmierstil recht sinvollNicht generell!
Im folgenden Fall völliger Unsinn:
void somefunc() { Daten* ptr = new Daten; ptr->.... delete ptr; ptr = NULL; // oft zu sehen - Blödsinn } class Foo { Daten* m_ptr; public: Foo() {m_ptr = new Daten[...];} ~Foo() {delete[] m_ptr; m_ptr = NULL; // Blödsinn - Objekt wird sowieso zerstört } };
Sinnvoll ist es nur dann, wenn man zum Beispiel eine Komposition in einem Objekt hat, die die Kardinalitäten 0..1 oder 0..n hat und diese mit Zeigern realisiert. Denn 0..1 kann heißen: Objekt da oder nicht da, beides erlaubt. Nicht-Da wird durch NULL-Zeiger realisiert.
class Foo { Daten* m_ptr; public: Foo() : m_ptr(NULL) {} ~Foo() {delete m_ptr;} attachObject() {delete m_ptr; m_ptr = new Daten;} detachObject() {delete m_ptr; m_ptr = NULL;} };
Dann macht es Sinn.
In C++ gibt's doch die Philosophie, daß man nur ausführen soll, was man benötigt. Ein generelles NULLen von Zeigern wäre aber unnützer Code, da nicht immer sinnvoll. Also abhängig vom Fall!!
[ Dieser Beitrag wurde am 30.06.2003 um 19:48 Uhr von Marc++us editiert. ]
-
Original erstellt von Marc++us:
**Bis zum Programmende [in früheren Betriebssystemen sogar teilweise noch über das Programmende hinaus]
**Heißt das auf heutigen Betriebssystemen kann man ruhigen Gewissens Objekte auf den Heap legen ohne sie wieder zu löschen, wenn man garantieren kann, dass:
- Der Code, welcher die Objekte erzeugt nur einmal ausgeführt wird
- Die Objekte tatsächlich erst bei Programmende zerstört werden sollen
?
Oder ist die Speicherloch-Phobie noch derart in den Köpfen der Programmierer, dass grundsätzliches "deleten" von gutem Stil zeugt ?
Nur eine Frage aus reinem Interesse...nicht weil ich zu faul für das ein oder andere delete bin
Gruß, space
-
das objekt auf dem heap bringt dir dann aber nichts mehr.
kein dtor aufruf zerstört es
große objekte, die nichts tun, sind unnütze resourcenfresser
-
Original erstellt von space:
Oder ist die Speicherloch-Phobie noch derart in den Köpfen der Programmierer, dass grundsätzliches "deleten" von gutem Stil zeugt ?Das ist wohl durchaus ein Argument.
Aber es gibt noch ein anderes: wenn Du wirklich objektorientiert programmierst, so besteht Dein Programm aus einer Sammlung von Objekten, die wiederum Objekte sind, usw. Nach unten hin wirst Du immer Inseln von Objekten finden, die zusammen arbeiten. Ist das Programm wirklich richtig designt, so ergibt sich automatisch daß beim Aufräumen eines solchen Clusters der Heap wieder den Ausgangszustand hat.
Wenn also Objekte nach der Zerstörung alles aufgeräumt haben, so ist es nur logisch, daß dies auch für das alleroberste Objekt gilt.