qtforum.de

1) Lizensierung: Ich möchte mich nur noch einmal vergewissern, ob das so richtig ist: Ich möchte eine Software verkaufen, die Qt benutzt (nicht den Quellcode, d.h. closed source). Ich ändere keine Qt-Klassen und ich linke dynamisch, somit ist der LPGL-Part und meine Applikation getrennt. Nach dem Lesen diverser Quellen im Internet benötige ich dazu KEINE Entwicklerlizenz. Stimmt das?

2) Weitergabe der Software (Windows): bisher kopiere ich einfach alle benötigten dlls in dasselbe Verzeichnis wie die entstehende exe und es funktioniert. Sind andere Wege besser / professioneller? (ich persönlich halte nichts vom installieren / registrieren im Windows selbst)

3) Garbage collection: bspw. erstelle ich einen Button so (ja, ich erstelle mein UI im Quellcode - sinnvoll oder nicht?):

Code: Alles auswählen

    QPushButton *tasR2_0 = new QPushButton("Neuer Job",this);
    connect(tasR2_0, SIGNAL(clicked()),
            this, SLOT(tasR2_0()));

Später wird die Taste in diverse Layouts gesteckt usw. Trifft der nächste Satz so zu? Alles, was im UI angezeigt wird, wird durch Qt selbst deleted! Würde heißen, dass das this im Beispiel überflüssig wäre. Eigene Klassen werden im jeweiligen Destruktor der erstellenden Klassen deleted. Ist es trotzdem sinnvoll, zu schauen, ob Speicherlecks vorhanden sind? Welche Programme / Vorgehensweise benutzt ihr in Windows?

4) eigene Klassen sollen zur Kommunikation untereinander Signals/Slots beherrschen (z.B. Benutzung einer gemeinsamen Ausgabe - QTextEdit ). Ich lasse sie dazu public von QObject erben. Ist so etwas aus Profisicht bedenklich?

Danke fürs Grundlagen beantworten

,
dd0815

Hi
Zu 1)
Ja das stimmt brauchst du nicht.

Zu 2)
Hängt davon ab wer dein Benutzerkreis ist. Ich hatte unlängst mit einem Fall zu tun wo der Benutzer (männlich 15 Jahre alt) nicht wuste das eine „setup.exe“ die Installation bzw. das Programm startet.
Er hat immer nur die erste Datei im Ordner angeklickt und mir den Fehlercode zugesendet mit der Meldung „die „Installation / der Programmstart“ ist defekt.
Bei der Installation bzw. Entpacken kannst du zumindest anbieten eine Verknüpfung am Desktop anzulegen.
Du musst deine Software nicht gleich bei Windows registrieren sonder kannst sie als „portable“ benutzen.

Zu 3)
Wenn du selber einen Destruktor verwendest teilst du Qt damit mit das der „Garbage collector“ für den Inhalt dieser Klasse nicht benötigt wird.
Somit ist es etwas gefährlich wenn du eine Mischung aus beiden benutzt und dein code verschachtelt ist.
Ich halte mich an die Regel Ganz oder Garnicht oder wenn es sein muss dann nur in seperaten gekapselten Modulen.
IMHO: UI im code zu erstelle ist das einzig Wahre

Zu 4)
Wieso sollte das bedenklich sein?
Außerdem kannst du Signals/Slots nicht verwenden wenn QObject wegläst.
Denn erst der preprocessoer stellt dir diese Funktionen als code zur Verfügung.

Hulk2442 hat schon alles beantwortet, ich habe noch ein paar Ergänzungen:

dd0815 hat geschrieben: 2) Weitergabe der Software (Windows): bisher kopiere ich einfach alle benötigten dlls in dasselbe Verzeichnis wie die entstehende exe und es funktioniert. Sind andere Wege besser / professioneller? (ich persönlich halte nichts vom installieren / registrieren im Windows selbst)

Natürlich nicht die zustätzlich benötigten Plugins (z.B. imageformats) vergessen, am besten die App auf einem frisch aufgesetzen OS testen (z.B. Virtuelle Maschine), bei dem Qt selbst nicht installiert ist (sonst merkt man fehlende Dlls eventuell nicht, da diese automatisch aus dem Qt-Ordner verwendet werden).
Die übliche Variante ist natürlich ein Setup-Programm zu erstellen (z.B. mit InnoSetup), man kann auch alles in ein ZIP packen, aber ich glaube nicht jeder weiss damit umzugehen und die richtige Datei (.exe) im Archiv anzuklicken, da ja dort auch .dll 's liegen.
Du kannst auch ein selbstentpackendes Archiv, das die enthaltene Exe automatisch startet, erstellen. Schau dir mal 7zip an (7zS.sfx, config.txt). Dann hat man nur eine .Exe, beim starten entpackt sich die Exe/Archiv mit der App-Exe und Dlls in ein temporäres Verzeichnis und die App-Exe wird automatisch gestartet. Klappt prima und der Kunde hat nur eine Datei.

dd0815 hat geschrieben: 3) Garbage collection: bspw. erstelle ich einen Button so (ja, ich erstelle mein UI im Quellcode - sinnvoll oder nicht?):
Code: Alles auswählen
    QPushButton *tasR2_0 = new QPushButton("Neuer Job",this);
    connect(tasR2_0, SIGNAL(clicked()),
            this, SLOT(tasR2_0()));

Qt/C++ hat keine "Garbage collection". Wenn du ein neues Objekt anlegst (new QPushButton), dann gibts du am besten den Parent für das Objekt an (also das Widget in dem der Button liegt). der Button ist nun ein Kind (Child) des Widgets und wenn das Widget (Parent) zerstört wird, dann zerstört der Parent auch alle seine Kinder. Du musst dich beim delete des Widgets also nicht mehr um das delete aller Objekte innerhalb des Widgets kümmern.
Gibts du beim Erstellen eines Objekts mit new keinen parent an, dann musst du irgendwann das mit new erstellte Objekt auch selber wieder mit delete löschen.

Hallo Hulk2442 / softwaremaker,

vielen Dank für Eure Antworten.

nochmal zu 3)
Ich dachte bisher, durch das addWidget / addLayout wird auch eine Eltern-/Kind-Beziehung zwischen den UI-Elementen aufgebaut, und beim Beenden der Applikation würde diese so entstandenen Beziehungen automatisch vom Qt berücksichtigt und die Kinder deleted. Deshalb hatte ich gefragt...

Qt/C++ hat keine "Garbage collection". Wenn du ein neues Objekt anlegst (new QPushButton), dann gibts du am besten den Parent für das Objekt an (also das Widget in dem der Button liegt). der Button ist nun ein Kind (Child) des Widgets und wenn das Widget (Parent) zerstört wird, dann zerstört der Parent auch alle seine Kinder. Du musst dich beim delete des Widgets also nicht mehr um das delete aller Objekte innerhalb des Widgets kümmern.
Gibts du beim Erstellen eines Objekts mit new keinen parent an, dann musst du irgendwann das mit new erstellte Objekt auch selber wieder mit delete löschen.

Wenn du selber einen Destruktor verwendest teilst du Qt damit mit das der „Garbage collector“ für den Inhalt dieser Klasse nicht benötigt wird.
Somit ist es etwas gefährlich wenn du eine Mischung aus beiden benutzt und dein code verschachtelt ist.
Ich halte mich an die Regel Ganz oder Garnicht oder wenn es sein muss dann nur in seperaten gekapselten Modulen.

D.h. sobald ich einen Destruktor anlege, reisst Qt sinnbildlich die Arme hoch und sagt : "Na dann mach doch alles selbst"? Ich würde mir schon gern die Arbeit beim UI ersparen, aber wenns nicht anders geht, dann werde ich doch wohl alles selbst deleten müssen... Na gut, außerdem kann man ja alles testen, da beim doppelten deleten das Programm ja beim Beenden "abstürzt"

...

Um mal noch etwas weiter auszuholen: Ich erstelle meinen Button (siehe Beispielcode im ersten Beitrag) auf diese Weise, um ihn für die Laufzeit des Programms am "Leben" zu halten (will den Button ja ständig sehen). Wenn ich ihn nur lokal im Konstruktor erstellen würde, dann wäre er ja schon wieder weg, bevor ich ihn sehen kann. Wie macht ihr das mit den UI-Elementen?

Als Zeiger mit new (wie ich bisher)?

Code: Alles auswählen

    QPushButton *tasR2_0 = new QPushButton("Neuer Job",this);
    connect(tasR2_0, SIGNAL(clicked()),
            this, SLOT(tasR2_0()));

    QHBoxLayout *tab2HLayout = new QHBoxLayout();
    tab2HLayout->addWidget(tasR2_0,0,Qt::AlignLeft);

Oder alles nicht als Zeiger im Header deklarieren (also nicht den Heap benutzen), bspw. so?

Code: Alles auswählen

    QPushButton tasJob;

Bei letzterem würde sich ja das delete sparen (wie ihr merkt, ist die Grundlagen-Wissenslücke doch noch etwas größer

)

Bis dann,
dd0815

Hallo nochmal,

habe in der Qt-Hilfe im Abschnitt QtCore > Object Trees & Ownership folgendes gefunden:

QWidget, the fundamental class of the Qt Widgets module, extends the parent-child relationship. A child normally also becomes a child widget, i.e. it is displayed in its parent's coordinate system and is graphically clipped by its parent's boundaries. For example, when the application deletes a message box after it has been closed, the message box's buttons and label are also deleted, just as we'd want, because the buttons and label are children of the message box.

Nehmen wir mal meinen Beispielcode von vorhin:

Code: Alles auswählen

    QPushButton *tasR2_0 = new QPushButton("Neuer Job",this);
    connect(tasR2_0, SIGNAL(clicked()),
            this, SLOT(tasR2_0()));

    QHBoxLayout *tab2HLayout = new QHBoxLayout();
    tab2HLayout->addWidget(tasR2_0,0,Qt::AlignLeft);

... sollte für ein automatisches Löschen von Qt eigentlich so aussehen:

Code: Alles auswählen

    QHBoxLayout *tab2HLayout = new QHBoxLayout(this); // parent ist das Mainwindow

    QPushButton *tasR2_0 = new QPushButton("Neuer Job",tab2HLayout);
    connect(tasR2_0, SIGNAL(clicked()),
            this, SLOT(tasR2_0()));

    tab2HLayout->addWidget(tasR2_0,0,Qt::AlignLeft);

Also eher "Top-Down" programmieren statt "Bottom-Up".

Alternativ kann ich doch auch alle UI-Elemente im Mainwindow erstellen und als parent eben this angeben, dann dürfte ich doch auch keine Probleme haben, oder?

Bleibt die Frage, ob ein selbstgeschriebener Destruktor den Qt-Mechanismus deaktiviert...

dd0815

Hallo nochmal,

ich versuche grade, mein UI etwas strukturierter zu coden, was die Parents angeht:

Code: Alles auswählen

    // Reiter 2
    QWidget *tab2 = new QWidget(this); // Parent mainWindow
    QVBoxLayout *tab2VLayout = new QVBoxLayout(tab2);
    QHeaderView *headJobList = new QHeaderView(Qt::Horizontal,tab2);
    QTreeView *treeJobList = new QTreeView(tab2);
    QHBoxLayout *tab2HLayout = new QHBoxLayout(tab2);
    QPushButton *tasR2_0 = new QPushButton("Neuer Job",tab2);

    tab2HLayout->addWidget(tasR2_0,0,Qt::AlignLeft);
    tab2VLayout->addWidget(treeJobList);
    tab2VLayout->addLayout(tab2HLayout);
    tab2->setLayout(tab2VLayout);
    tab2->show();

    ... etwas später ...

    centralTab = new QTabWidget(this); // Parent mainWindow
    ...
    centralTab->addTab(tab2,"Reiter 2");

Ziel: einen Reiter mit ein paar Objekten füllen... Es kompiliert zwar und startet, nur kommt die Debug-Meldung "QLayout: Attempting to add QLayout "" to MainWindow "", which already has a layout". Es sieht also so aus, als ob ich pro Widget nur ein Layout haben kann (im Beispiel sind es ja 2). Jetzt siehts grade so aus:

Code: Alles auswählen

    QWidget *tab2main = new QWidget(this);
        QVBoxLayout *tab2VLayout = new QVBoxLayout(tab2main);
        QHeaderView *headJobList = new QHeaderView(Qt::Horizontal,tab2main);
        QTreeView *treeJobList = new QTreeView(tab2main);
        QWidget *tab2reihe = new QWidget(tab2main);
            QHBoxLayout *tab2HLayout = new QHBoxLayout(tab2reihe);
            QPushButton *tasR2_0 = new QPushButton("Neuer Job",tab2reihe);
    ...

    tab2HLayout->addWidget(tasR2_0,0,Qt::AlignLeft);

    tab2reihe->setLayout(tab2HLayout);
    //tab2reihe->show();

    tab2VLayout->addWidget(treeJobList);
    tab2VLayout->addWidget(tab2reihe);

    tab2main->setLayout(tab2VLayout);

(Dabei ist mir aufgefallen, dass ich die Widgets gar nicht mit show anzeigen muss, wie ich es bisher getan habe) Würdet ihr das ähnlich strukturieren? (Nur dass ich mal ein Positiv-Beispiel habe

)

Nochmal zum MainWindow-Destruktur:

ich habe das Widget tab2main zum Test mal nicht lokal, sondern im Header deklariert, d.h. im Code siehts dann so aus:

Code: Alles auswählen

    tab2main = new QWidget(this);

und anschließend im Desktruktor mit "delete tab2main;" gelöscht. Das Programm wurde ordnungsgemäß beendet, d.h. es stürzte beim Beenden nicht ab. Also wird anscheinend mit meinem eigenen Destruktor Qt doch ausgehebelt (es wäre schön, an der Stelle mal ein klares Ja oder Nein zu hören). Theoretisch hätte ich ja kein Problem ohne Destruktor, aber meine eigenen Klassen möchte ich auch schon gerne wieder loswerden. Wie macht ihr das?

Vielen Dank für Eure Geduld

,
dd0815

Komme jetzt nicht ganz mit was deine Anliegen ist bzw. was du genau wissen möchtest.
Jedoch kannst du pro Widget/Label/usw. nur ein "Haupt Layout" zuweisen - in dieses Hauptlayout kannst du dann weiter Sachen verschachteln.

Oder anders gesagt stell dir vor du hast zwei Boxen
1 x Eine Box in der alle Sachen Horizontale liegen
1 x Eine Box in der alle Sachen Vertikale liegen
Wie stapelst du diese Boxen in einem Zimmer - Übereinander, Hintereinander, Nebeneinander, welche Kommt zuerst welche danach ?
Das ist das gleiche mit Widget(Zimmer) und zwei Layouts(Boxen).

Was meinst du mit "dass ich die Widgets gar nicht mit show anzeigen muss" ?
Wenn die Objekte ineinander verschachtelst reicht ein einziges show (im main) aus um alles anzuzeigen.

Hallo Hulk2442,

Code: Alles auswählen

    QWidget *tab2main = new QWidget(this);
        QVBoxLayout *tab2VLayout = new QVBoxLayout(tab2main);
        QHeaderView *headJobList = new QHeaderView(Qt::Horizontal,tab2main);
        QTreeView *treeJobList = new QTreeView(tab2main);
        QWidget *tab2reihe = new QWidget(tab2main);
            QHBoxLayout *tab2HLayout = new QHBoxLayout(tab2reihe);
            QPushButton *tasR2_0 = new QPushButton("Neuer Job",tab2reihe);

ich habe versucht, die Struktur mit den Einrückungen klar zu machen. Im Reiter, dessen Inhalt im QWidget tab2main gesammelt wird, gibt es eine vertikale Box (tab2VLayout ), in der zuerst eine Tabelle mit Header liegt und in der darunter eine horizontale Box (tab2HLayout) liegt, die eine Taste beinhaltet. Als Parent wollen die UI-Elemente ja ein QWidget angeben, weswegen ich bspw. bei der horizontale Box nicht einfach die übergeordnete vertikale Box als Parent angeben kann. Daher habe ich jetzt noch das Hilfswidget tab2reihe angelegt... Zuerst werden also alle UI-Elemente angelegt, und anschließend einander zugewiesen:

Code: Alles auswählen

    treeJobList->setHeader(headJobList);

    tab2HLayout->addWidget(tasR2_0,0,Qt::AlignLeft);
    tab2reihe->setLayout(tab2HLayout);

    tab2VLayout->addWidget(treeJobList);
    tab2VLayout->addWidget(tab2reihe);

    tab2main->setLayout(tab2VLayout);

Also dem TreeView der Header, der horizontalen Box die Taste, anschließend dem "Hilfswidget" tab2Reihe die horizontale Box. Nun noch der vertikalen Box das Treeview und das Hilfswidget tab2Reihe und zuletzt dem Hauptwidget tab2main die vertikale Box, in der sich mittlerweile alle Elemente des Reiters befinden.

Ich wollte nur wissen, ob Du bei derselben Aufgabenstellung vergleichbaren Code produzieren würdest, oder ob Du die Aufgabe ganz anders angehen würdest.

Das mit der show-Funktion ist mir eben auch aufgefallen (hab ich bloß noch einmal verbalisiert

).

Mein Schwerpunkt liegt allerdings aber nach wie vor im Verstehen des ganzen "Deletens" des UIs. Da obiger Code ja im Konstruktor vom mainwindow stattfindet, kann ich ja in einem Destruktor nicht mehr direkt auf bspw. tab2main zugreifen, d.h. selbst wenn ich selbst alles selbst deleten möchte, müßte ich eigentlich jedes UI-Element als Membervariable deklarieren. Das hatte ich eben mal mit dem tab2main gemacht und dann eben im Desktruktor deleted. Und da das Programm beim Beenden nicht abgestürzt ist, wird wohl das Deleten erfolgreich gewesen sein, d.h. Qt hat es nicht selbst gelöscht...

Und hier wollte ich nun auch wissen, wie das deleten bei Euch aussieht (wenn ihr es selbst macht). Deklariert ihr wirklich alle UI-Elemente als Membervariablen? Verteilt ihr die UI-Elemente in Klassen? Erzeugt ihr eure selbst geschriebenen Klassen gar nicht im mainWindow? (so dass ihr den Destruktor nicht selbst schreiben müßt) Allgemein möchte ich einfach gern wissen, wie ein "korrektes" Projekt mit einigen UI-Elemente und einer eigenen Klasse bei Euch so aussieht (eben das Anlegen und eben auch das Löschen), oder wo ich mal ein diesbezügliches Beispiel finde - Grundlagen halt

dd0815

Hi
Sorry für die Lange Antwort jedoch war ich letzten paar tage weg.
Ich habe deinen Code etwas strukturiert und in ein Beispiel zusammengesetzt.

Im Grunde bist du auf dem richtigen Weg - jedoch kannst du zwei Sachen weglassen.

1.) Das Widget für die 2te Reihe „QWidget *tab2reihe“
Es ist nämlich möglich Layouts in einander zu verschachteln somit musst du nicht jedes Layout in ein eigenes Widget zwängen.

2.) Die Zuweisung der Eltern Objekte wenn du die Kinder Objekte erzeugst.
Denn die Zuweisung als Kinder machst du eine Zeile später wodurch eine doppelte Eingliederung durchgeführt wird.

Aus eigener Erfahrung würde ich meinen dass beim programmieren einer GUI es am einfachsten ist wenn du dir diese als eine Hierarchie vorstellst, welche du von letzten zum ersten Objekt abarbeitest.

Code: Alles auswählen

MainWindow
	+--> HubWidget
			+--> tab2VLayout
					+--> treeJobList
					|		+--> headJobList
					+--> tab2HLayout
							+--> tasR2_0

Was den Zerstören der Kinder angeht so werden diese in ihrer Abhängigkeit zu einander zerstört.
Also wenn das Elternobject zerstört wird werden auch dessen Kinder zerstört.
Obwohl in diesem Beispiel keine Eltern beim Konstruieren mitgegeben werden, werden durch die Zuweisung von Kindern die Objekte automatisch zu Eltern berufen.

Denn du kannst ja sagen „du bist mein Elternobjekt“ oder „ich bin dein Kindobjekt“ --> beides führt zu einer Eltern/Kind Beziehung.

Um das etwas zu verdeutlichen habe ich den Button von dir mit einem kleinen „clickSlot“ verbunden welcher das Elternobjekt vergleicht.

Hallo Hulk2442,

vielen Dank für Dein Beispiel, aus dem ich einiges rauslesen kann:

1) Du hast ein Teil des UIs in einer eigenen Klasse erstellt (HubWidget) - Das hab ich gestern auch für mich entdeckt, womit die Klasse mainWindow viel übersichtlicher wird

2) Du deklarierst also tatsächlich alle UI-Elemente als Membervariablen - spielt das für das automatische Löschen durch Qt wirklich eine Rolle? (siehe meinen letzten Beitrag)

3) Durch die Zuweisung der UI-Elemente zueinander entsteht auch die Eltern-Kind-Beziehung, so dass ich beim Anlegen keinen Parent angeben muss (somit brauche ich natürlich kein Hilfswidget anlegen) - hab ich jetzt verstanden

Was für mich nach wie vor nicht klar ist:

3) Wird durch das Anlegen eines Destruktors das automatische Löschen durch Qt aufgehoben? Zur Erläuterung der Wichtigkeit dieser Frage: In eigenen Klassen benutze ich QStandardItemModels sowie QLists mit Zeigern auf die Instanzen einer Subklasse (bspw. kommuziere ich mit Maschinensteuerungen via TCP und lasse die verbundenen Maschinen via QStandardItemModel in einer QTableView darstellen. Intern benutzt die Maschineklasse auch ein QStandardItemModel zum Speichern der Daten (Darstellung in einer QTreeView). Diese Klassen benötigen einen Destruktor zum Löschen der Models sowie der Subklasseninstanzen...

Code: Alles auswählen

commTcp::~commTcp()
{
    delete tcpServ;
    qDeleteAll(lClients); // alle Clients löschen
    lClients.clear();
}

4) Meine eigenen Klassen erben public von QWidget (siehe code, wegen siehe 1.) oder auch QObject (wegen der Signale / Slots) - Somit müssten diese doch auch den Eltern-Kind-Beziehungsmechanismus haben und sobald ich Parents angegeben habe automatisch gelöscht werden?

Code: Alles auswählen

class commTcp : public QWidget
{
...
}

Code: Alles auswählen

commTcp::commTcp(QWidget *parent) //: QWidget(parent)
{
... 
}

Was bedeutet eigentlich das ": QWidget(parent)"?

Ich weiß, die Fragereien erscheinen wie ein Faß ohne Boden, aber ich glaube Du hast es bald geschafft...

Einen schönen Tag,
dd0815

Hi
@1
Ja Auslagern wenn es Sinn macht – wenn es eine für sich abgeschlossenes Logik ist umso mehr.

@2
Ich deklariere sie in erster Linie nicht wegen dem Löschen sondern wegen der Übersicht und der Möglichkeit jederzeit auf diese zuzugreifen.
Des weiteren fängt jedes Projekt klein an und wächst in Komplexität und Konnektivität. Damit ich(oder ein Kollege) eine Übersicht über die UI Elemente bekomme muss nur das Header File geöffnet werden und durch lesen von ein paar Zeilen ist dass meiste klar.

@3
Habe jetzt selber etwas nachlesen müssen …
http://qt-project.org/doc/qt-5/objecttrees.html
Mit anderen Worten Qt zerstört automatisch alle Child Objekte sofern sich diese von mindestens „QObject“ ableiten.

Ich würde sagen entweder du schaust das alle Klassen welche du verwendest von Qt abgeleitet sind dann sollte es automatisch funken oder du schreibst für die eine spezielle Klasse selbst einen Destruktor.

Den TCP Destructor würde ich auch belassen.
Zwar schlissen sich alle Verbindungen wenn die Software an sich beendet wird jedoch ist das ein Abruptes schließen und manche Hardware interpretiert das als Absturz.

@4
Das ist korrekt!

@": QWidget(parent)"
Damit informierst du das Qwidget über sein Parent. Das Child wird dabei auch direkt diesem Parent untergeordnet.

dd0815 hat geschrieben:Was bedeutet eigentlich das ": QWidget(parent)"?

Das ist die Initialisierungsliste. Eine C++ Spezialität, die m.E. zu den Grundlagen gehört:

http://www.online-tutorials.net/c-c++-c ... rungsliste

Hallo Hulk 2442,

so, ich hab jetzt erst mal keine Fragen mehr und möchte dieses Thema schließen. Ich möchte Dir nochmals vielmals für Deine vielen Antworten danken, Du hast mir sehr geholfen

@MichaelS: Danke auch für Deine Antwort und den Link...

bis dann,
dd0815

P.S. ich würde den Beitrag gern als gelöst kennzeichnen, habe aber keine Ahnung wie

Hi
Bitte schön
Um als gelöst zu setzen musst du den ersten Post editieren und [solved] vor dem Titel einfügen.

Ich würde sagen entweder du schaust das alle Klassen welche du verwendest von Qt abgeleitet sind dann sollte es automatisch funken oder du schreibst für die eine spezielle Klasse selbst einen Destruktor.

Das "oder" ist da bissi verwirrend ^^

generell, die ObjectHirachrie (Parent - Child) wird komplett ueber QObject abgewickelt.
Das heisst im CTOR und DTOR werden alle notwendigen dinge getan, um die Beziehung aufzubauen, bzw die Beziehungen abzubauen und die elemente zu löschen.
Der CTOR und DTOR von QObject wird immer mit aufgerufen, auch wenn du "nur" ableitest

Also auch wenn du einen eigenenen DTOR schreibst, wird der DTOR von QObject aufgerufen, welcher auch alle Childs löscht !
Es sei denn Du löschst sie selber vorher ^^
Andersrum ausgedrueckt, wenn Parent und Childs in ner QObject-Hirarchie sind( und damit alle von QObject ableiten), musst du dich nicht ums löschen kümmern, auch wenn Du selber nen DTor für eine von den Klassen schreibst !
Willst Du das sie nicht automatisch geloescht werden, duerfen sie nicht in die Object-Hirarchie sein (parent auf nullptr initialisieren, oder vorm destructor rauslösen)!

Ciao ...

qtforum.de

[solved] einige Fragen (Lizenzierung, Weitergabe, Garbage)

[solved] einige Fragen (Lizenzierung, Weitergabe, Garbage)

Re: einige Fragen (Lizenzierung, Weitergabe, Garbage

Re: einige Fragen (Lizenzierung, Weitergabe, Garbage

Re: einige Fragen (Lizenzierung, Weitergabe, Garbage

Re: einige Fragen (Lizenzierung, Weitergabe, Garbage

Re: einige Fragen (Lizenzierung, Weitergabe, Garbage

Re: einige Fragen (Lizenzierung, Weitergabe, Garbage

Re: einige Fragen (Lizenzierung, Weitergabe, Garbage

Re: einige Fragen (Lizenzierung, Weitergabe, Garbage

Re: einige Fragen (Lizenzierung, Weitergabe, Garbage

Re: einige Fragen (Lizenzierung, Weitergabe, Garbage

Re: einige Fragen (Lizenzierung, Weitergabe, Garbage

Re: einige Fragen (Lizenzierung, Weitergabe, Garbage

Re: einige Fragen (Lizenzierung, Weitergabe, Garbage)

Re: [solved] einige Fragen (Lizenzierung, Weitergabe, Garbag