f.o.g. hat geschrieben:und was genau spricht jetzt gegen meine Lösung?
Sie ist nicht wirklich sauber, da es die EventLoop für etwas nutzt, was du mit normalen C++-Programmierparadigmen besser lösen kannst, die dann auch immer zuverlässig funktionieren. Bei deiner Lösung musst du nur auf die Idee kommen, das closeEvent() zu implementieren, und event->ignore() aufzurufen, und das close() schließt das Widget nicht und beendet auch nicht das Programm. Viel Spaß beim Fehlersuchen
Es kann auch Probleme geben, denn ein close() schließt nur das Fenster, falls das Flag WA_DeleteOnClose gesetzt ist. Und dein Programm bricht eben doch nicht ab, wenn nur das eine Widget sich beendet. Wenn das das MainWindow ist, und keine anderen unabhängen QWidget rumfliegen bedeutet das auch das Ende für dein Programm.
Dann ist ein im Konstruktor vorbereiteter Selbstzerstörungsmechanismus für den Verwender der Klasse absolut undurchsichtig, denn er erstellt ein Objekt, erkennt nicht ob die Erstellung funktioniert hat und verlässt sich während dem Programmverlauf auf dessen Existenz. Und plötzlich wird das Ding zerstört :/
Lass z.B. in der EventQueue auch ein Event liegen, das das erstellende Objekt dazu veranlasst, auf dein AutoDelete-Objekt zuzugreifen. Dann nimm auch an, dass dein Widget das close() vor dem anderen Event bekommt. Das bedeutet SegFault

da du nach dem Zerstören in dem noch ausstehenden Event auf das zerstörte Objekt zugreifen willst - auf NULL prüfen geht auch nicht, da nach delete eben der Pointer NICHT auf NULL gesetzt wird, sondern auf den deinitialisierten Speicherbereich zeigt.
Ich weiß, etwas verworren, aber so ist das, die Fallstricke sind bei deiner Methode so diffiziel und vielfältig, dass es beim Drüberstolpern schwer ist sie auszumachen.
Bei den beiden oben erwähnten Lösungen (Exception im Konstruktor, Factory-Methode die bei Fehler NULL zurückgibt) existieren diese Fallstricke eben nicht.