ich habe eine Map, die so aussieht: map<string, A*> myMap;

Wenn ich mir den Iterator besorge (map<string, A*>::iterator myIt), kann ich ja mittels "second" auf den zeiger und damit weiter auf die public-Eigenschaften der Klasse A zugreifen.

Vorher muss ich jedoch ein Objekt der Klasse A dynamisch mit new erzeugen.
Jetzt taucht aber ein Problem auf - nämlich beim Löschen der Objekte:

Wenn ich mit einer for-Schleife über die map iteriere, lösche ich die einzelnen Objekte mit "delete myIt->second". Gibt auch keinen Fehler beim compilieren.
Wenn ich nun noch einmal auf die Objekte zugreifen würde, müsste es ja einen fehler geben - gibt es aber nicht!!!
Ich kann nach wie vor auf den Objekten über die Zeiger in der Map arbeiten.
Kann mir jemand sagen, wo mein Fehler liegt? Oder ob das normal ist?!

Gruß
Sdy

Wenn ich mit einer for-Schleife über die map iteriere, lösche ich die einzelnen Objekte mit "delete myIt->second". Gibt auch keinen Fehler beim compilieren.

Ist auch okay...

sheddy schrieb:

Wenn ich nun noch einmal auf die Objekte zugreifen würde, müsste es ja einen fehler geben - gibt es aber nicht!!!

Nein, muss es nicht. Es ist schlicht und ergreifend undefiniert.

Ein auf einen Zeiger angewendetes delete ruft den Destruktor auf und gibt den Speicher frei, verändert aber den Speicherbereich nicht zwangsweise. Das heißt, wenn du über diesen Zeiger zugreifst, und noch nichts anderes dessen Platz eingenommen hat, du durchaus auf die "Reste" heran kommst.

Aber wie gesagt: Dies ist undefiniertes Verhalten, man sollte sich nicht darauf verlassen. Wenn du tatsächlich einen Fall hast, in dem du die Zeiger als ungültig markieren willst, setze sie nach dem delete auf NULL.

Die Klasse A hat einen string (<string>) als Eigenschaft! muss ich den irgendwie explizit freigeben? Den String lasse ich im Konstuktor initialisieren und rufe ihn nicht mit "new string()" auf.

Denn wenn ich den zeiger für das Objekt A lösche, kann ich auf den String danach noch drauf zugreifen Auf andere Eigenschaften wie z.B. Integer wird irgendeine Zahl und nicht die damals im Objekt gespeicherte ausgegeben.

Die Klasse A hat einen string (<string>) als Eigenschaft! muss ich den irgendwie explizit freigeben?

Nein, musst Du nicht.

@firefighter: Was hat die boost-bibliothek für einen vorteil? Ich habe gerade mal kurz nach geguckt und irgendwie konnte ICH auf die schnelle nichts brauchbares finden
Kannst kurz sagen, was die bibliothek für ein vorteil hat? Ist es einfach nur einfacher damit zu programmieren oder sind die einzelnen dinger wie container wie z.b. deine vorgeschlagene map besser implementiert?

Die Klasse A hat einen string (<string>) als Eigenschaft! muss ich den irgendwie explizit freigeben? Den String lasse ich im Konstuktor initialisieren und rufe ihn nicht mit "new string()" auf.

In der Regel kannst du in C++ davon ausgeben, das du nur dort Speicher freigeben musst, wo du auch den Speicher anforderst (Für jedes new genau ein delete, für jedes new[] genau ein delete[]).

cu André

@firefighter: Was hat die boost-bibliothek für einen vorteil? Ich habe gerade mal kurz nach geguckt und irgendwie konnte ICH auf die schnelle nichts brauchbares finden

Die Boost-Bibliothek ist eine der IMHO mächtigsten portablen Bibliothekssammlungen zu C++ (Zum Teil sind diese Bereits für den nächsten Standard vorgeschlagen). Beispiele für Bibliotheken die ich häufiger verwende: Bind, Functional, Smart Ptr... (und auch die Pointer Container Library die für dich interessant sein könnte sind durchaus interessant).

sheddy schrieb:

@firefighter: Was hat die boost-bibliothek für einen vorteil? Ich habe gerade mal kurz nach geguckt und irgendwie konnte ICH auf die schnelle nichts brauchbares finden

Die Boost-Bibliothek ist eine der IMHO mächtigsten portablen Bibliothekssammlungen zu C++ (Zum Teil sind diese Bereits für den nächsten Standard vorgeschlagen). Beispiele für Bibliotheken die ich häufiger verwende: Bind, Functional, Smart Ptr... (und auch die Pointer Container Library die für dich interessant sein könnte sind durchaus interessant).

Und auch so tolle Sachen wie nahezu plattformunabhängige Threads oder Netzwerkkommunikation sind enthalten.