aha, non-class type, obwohl als Klasse definiert? II

Okay Leute,
ich will gar nicht so tun, als könnte ich es auch alleine schaffen. Hier wäre das nächste Problem. Die Klassendefinitionen stehen im alten Thread, ich denke aber mal nicht, dass die vonnöten sind. Hier meine main-Funktion:

-------------------

int main(void)
{

        ListenElement Liste[2];

        Liste[0]=ListenElement();
        Liste[1]=IntElement(50,0,0);

        Liste[0].Print();
        Liste[1].Print();

        delete(&Liste[0]); delete(&Liste[1]);
}

----------------------
Leider führt das delete in der letzten Zeile beim Ausführen der kompilierten Datei zu einer Fehlermeldung:

----------------------------------------
*** glibc detected *** ./a.out: munmap_chunk(): invalid pointer: 0xbf8231d0 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(cfree+0x1bb)[0xb7ce192b]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb7ea5d81]
./a.out(__gxx_personality_v0+0x21e)[0x8048822]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7c8a050]
./a.out(__gxx_personality_v0+0x3d)[0x8048641]
======= Memory map: ========

...... und so weiter
--------------------------------------------

drakon

delete(&Liste[0]); delete(&Liste[1]);

WTF?

Mal einer, der es umgekehrt macht.

delte/delete[] musst du nur machen, wenn du den Speicher explizit selber per new/new[] anforderst. Das wird alles am Ende des Scopes der Definition automatisch erledigt.

Jau, im Buch war "Liste[2]" eigentlich als Liste von Pointern auf ListenElemente geschrieben und Liste[1/2] waren mit new instanziiert worden.

Soll ich das dahingehend verstehen, dass der Speicher bei Anforderung durch new auch noch nach Ende des ganzen Programmes reserviert und dadurch erstmal unbrauchbar ist?

Nexus

Nein, das hat nichts damit zu tun.

Du musst zwischen Stack (automatische, statische Speicherverwaltung) und Heap (dynamische Speicherverwaltung, mit new / new[] angefordert und mit delete / delete[] freigegeben) unterscheiden.