Garbage Collector

[AlexanderKiebler]

Na ja Also die QT baut ja einen Abhängigkeitsbaum auf.
Die mit new erzeugten Objekte werden dann automatisch vom Speicher genommen.
Man kann das Nachvollziehen, wenn man die destruktoren impelemntiert.

So war das gemeint. Bei reinem C/C++ muss er natürlich....
Und bei der QT wird auch zerstört, aber eben automatisch.

Habe aber noch ein anderes Problem.

Ich habe den Operator

void operator delete[] (void * ptr);

überladen.
Leider wird bei

delete[] *instances_arr_it;

leider der operator

void operator delete (void * ptr);

aufgerufen, was zu einem Speicherabsturz führt.
Woran liegt denn das ??
*instances_arr_it ist vom Typ const GaCo *

Gruß

[unrego]

AlexanderKiebler schrieb:

Woran liegt denn das ??

lies mal ein anfängerbuch.

[AlexanderKiebler]

Keine Lust mir weiter zu helfen ??

[l'abra d'or]

AlexanderKiebler schrieb:

Und bei der QT wird auch zerstört, aber eben automatisch.

Nein, nicht automatisch! Parents löschen ihre children. Wenn du das Toplevel-parent nicht löschst, werden auch die children nicht gelöscht. Und das Verhalten ist nachvollziehbar und vom Benutzer durchschaubar und vor allem kontrollierbar - vor allem hier aber notwendig, denn bei verschachtelten Fensterlayouts wird es müßig, ständig beim Zerstören selber rekursiv über alle children zu iterieren und zu löschen - und am Ende gehts doch schief
Wenn hingegen einem einfach automatisch ohne Kontrolle das Objekt unterm Hintern weggerissen wird, kann das böse enden.

[AlexanderKiebler]

Ja da hat du Recht, es wird nicht selten vergessen das Top-level Parent zu löschen.

Keine Angst ich ziehe niemandem Speicher unter der Nase weg. Das passt schon so bei mir, es ist sinnvoll und keine schlechte Idee. Das liegt am Komzept und an der Natur der Sache.
Ich kann dafür garantieren, dass die Objekte nicht mehr benötigt werden, wenn ich zum löschen anfange.
Und aus der Selben Motivation-- es wäre müßig und immer das Selebe -- lösche ich auch.

Würde mich aber über eine Antwort wegen dem delete[] operator freuen.

Habe gelesen dass die new und delete operatoren sowei new[] und delete[]
gerne kompilerabhängige optionen haben......

Gruß

[l'abra d'or]

Wieso klammerst du dich an die operator new/...-Überladung. Erstell dir eine Simulator-Klasse, der du Simulationen hinzufügen kannst. Biete eine Simulator::clear()-Methode an, welche alle Simulationen löscht. ~Simulator ruft natürlich auch clear() auf. Sorge dafür, dass das Simulator-Objekt garantiert spätestens bei Programmende zerstört wird. Punkt. Mehr brauchts doch nicht, oder?

Die Lösung von Krümelkacker ist sicherlich auch sehr schön, aber in meinen Augen für dich auch nicht unbedingt nötig.
Wenn es dir um das Verstehen von operator new/...-Überladung geht, dann ist das das falsche Beispiel.

Wg. Placement-new: die STL-Container verwenden AFAIK gerne mal Placement-new, wenn speicher zwar mit reserve angefordert wurde (oder Speicher von einem vorherigen remove() frei geworden ist), aber die einzelnen Elemente noch nicht initialisiert wurden. Sobald du deine Collactable-Objekte in einem (z.B.) vector ablegst, wirst du über das ein oder andere Placement-new stolpern.

[AlexanderKiebler]

Okay, das klingt jetzt schon einleuchtender. Danke für das Argument.
Ich hätte ein Problem mit der STL innerhalb der von GaCo abgeleiteten Klassen.
Oder ich müßte placement new überladen.
Kann man das nicht irgendwie mit

::new ....

delegieren ??

Also zunächst klammere ich mich da dran, weil ich mich dafür schon sehr interessiere, auch wenn es ier nicht die beste Lösung ist.

Kannst du mir ne Seite Sagen, wo new new[] delete und delete[] exakt beschrieben werden.

Wenn ich merke dass ich damit nicht zurecht komme, werde ich es wie empfohlen anderst machen. Trotzdem glaube ich sollte ich mich irgendwann auch mit den Operatoren zum Speicheranfordern genauer auseinandersetzen.
Ich halte das einfach für wichtig.

Gruß

[hustbaer]

AlexanderKiebler schrieb:

Na ja Also die QT baut ja einen Abhängigkeitsbaum auf.
Die mit new erzeugten Objekte werden dann automatisch vom Speicher genommen.
Man kann das Nachvollziehen, wenn man die destruktoren impelemntiert.

So war das gemeint. Bei reinem C/C++ muss er natürlich....
Und bei der QT wird auch zerstört, aber eben automatisch.

Dann darf er aber nicht mehr.
"Darf, muss aber nicht" gibt's in C++ üblicherweise einfach nicht.

[AlexanderKiebler]

Magst mir nicht ein gutes Beispiel zum Überladen von new und delete zeigen, wo ich schön lernen kann

Häuptling hustender Bär *ggg*

Arbeitest du bei den Licht Tools mit da du für sie wirbst *lach*
Woher hast denn das ??

Das Problem ist, ich interessiere mich echt dafür. So wie ich mich kenne werde ich immer wieder new und delete überladen wollen, solange bis ichs kann, und es uninteressant wird weils bessere lösungen gibt.

[hustbaer]

AlexanderKiebler schrieb:

Arbeitest du bei den Licht Tools mit da du für sie wirbst *lach*
Woher hast denn das ??

Ist ein Projekt eines Freundes von mir. Ich hab nur den native Win32 C++ Port gemacht.