Speicherleck bei QT-Widget?

Ruvi

axels. schrieb:

Wenn ich nur das Schreibe
QColorDialog* k = new QColorDialog(dynamic_cast<QWidget*>(this));
entsteht dennoch ein Speicherleck.

Edit: Noch besser funktioniert das ganze mit smart-pointern. Dann hat man auch kein Probelm mit delete wenn der Dialog nie aufgerufen wurde.

Also ich benutze in Qt auch std::smartpointer aber dein code sieht irgendwie ein wenig merkwürdig aus.

Wenn dein erstelltes Widget ein Parent hat dann muss es abgeräumt werden, wenn das nicht passiert stimmt irgendwas mit deinem Parent nicht oder die Art wie du es erstellt hast.

Dein dynamic_cast sollte auch vollständig überflüssig sein. Ich habe sowas im Code an der Stelle noch nie gebraucht.

Schlangenmensch

Ich würde raten, das die Klasse, aus der die Funktion aufgerufen wird, nicht von QWidget abgeleitet wird. Und dann geht das mit dem this Pointer natürlich nicht. Auch der Cast wird dann irgendwas zurück geben, was keinen Sinn ergibt.

firefly

Schlangenmensch schrieb:

Ich würde raten, das die Klasse, aus der die Funktion aufgerufen wird, nicht von QWidget abgeleitet wird. Und dann geht das mit dem this Pointer natürlich nicht. Auch der Cast wird dann irgendwas zurück geben, was keinen Sinn ergibt.

In diesem falle liefert dynamic_cast einen nullptr zurück wenn der cast nicht möglich ist.

Braunstein

Ich frage mich warum hier der ColorDialog überhaupt dynamisch erstellt wird. Sowas stellt doch meist ein modales Fenster dar. Somit könnte man diesen Dialog in einer Funktion als lokale Variable erzeugen. Dann gibts auch kein Problem mit dem Löschen.
Bei QDialog hat der parent ja noch eine weitere Bedeutung. Er stellt sicher wo der Dialog gezeichnet wird. Deswegen ist der parent hier auch ein QWidget und kein QObject.
Zum dynamic_cast. Normalerweise sollte man je wissen welchen Typ this hat. Somit sollte auch klar sein was der cast macht. Das ist alles so unnötig.

axels.

Der cast im Konstruktor des QColorDialogs machte wirklich keinen Sinn.

Braunstein schrieb:

Ich frage mich warum hier der ColorDialog überhaupt dynamisch erstellt wird. Sowas stellt doch meist ein modales Fenster dar. Somit könnte man diesen Dialog in einer Funktion als lokale Variable erzeugen. Dann gibts auch kein Problem mit dem Löschen.

Wenn ich den Dialog als lokale Variable erstelle binkt er kurz auf und verschwindet wieder sobald die Funktion verlassen wird.

Schlangenmensch schrieb:

Ich würde raten, das die Klasse, aus der die Funktion aufgerufen wird, nicht von QWidget abgeleitet wird.

Tatsächlich wird die Klasse polymorph von QTreeWidgetItem abgeleitet.

Finnegan

Braunstein schrieb:

Sowas stellt doch meist ein modales Fenster dar.

Tod allen modalen Dialogen!!!1einself!

Mechanics

Woher weißt du, dass es ein Speicherleck ist? Dein erstes Beispiel schaut auf jeden Fall danach aus, aber woher weißt du das?
Wenn sich irgendwelchen statischen Code Analyzer drüber beschweren, ist es noch kein Grund, denen zu glauben, die verstehen Qt nicht und können das nicht so genau analysieren. Nach dem Übergeben des Parents dürftest du kein Speicherleck mehr haben.

axels.

Mechanics schrieb:

Woher weißt du, dass es ein Speicherleck ist? Dein erstes Beispiel schaut auf jeden Fall danach aus, aber woher weißt du das?
Wenn sich irgendwelchen statischen Code Analyzer drüber beschweren, ist es noch kein Grund, denen zu glauben, die verstehen Qt nicht und können das nicht so genau analysieren. Nach dem Übergeben des Parents dürftest du kein Speicherleck mehr haben.

Das ist ja gerade die Frage die sich mir stellt. Soll ich meinem Wissen über QT trauen oder dem was mir die CRT-Bibliothek meldet.

Mechanics

Setz doch einfach einen Breakpoint im Destruktor, und schau ob das Ding wirklich gelöscht wird.

Braunstein

axels. schrieb:

Braunstein schrieb:

Ich frage mich warum hier der ColorDialog überhaupt dynamisch erstellt wird. Sowas stellt doch meist ein modales Fenster dar. Somit könnte man diesen Dialog in einer Funktion als lokale Variable erzeugen. Dann gibts auch kein Problem mit dem Löschen.

Wenn ich den Dialog als lokale Variable erstelle binkt er kurz auf und verschwindet wieder sobald die Funktion verlassen wird.

Wenn der Dialog nur kurz aufblinkt, dann rufst du ihn falsch auf. Es kommt jetzt darauf an was der Dialog machen soll.

axels. schrieb:

Schlangenmensch schrieb:

Ich würde raten, das die Klasse, aus der die Funktion aufgerufen wird, nicht von QWidget abgeleitet wird.

Tatsächlich wird die Klasse polymorph von QTreeWidgetItem abgeleitet.

QTreeWidgetItem ist ungeeignet als parent für den Dialog da es nicht von QWidget, ja noch nicht mal von QObject abgeleitet ist. Du könntest aber als Parent den parent von deiner QWidgetItem-Klasse nehmen. Das sollte ja ein QTreeWidget sein und ist somit verwendbar.

Das Ganze gehört aber langsam ins Qt-Forum.

axels.

Ok, jetzt abschließend eine richtige Lösung:

QColor color = QColorDialog::getColor();

Kommt ganz ohne dynamisches Objekt aus.

Warum hab ich das von Anfang an nicht so gemacht?
Weil ich die Möglichkeit einfach nicht kannte.