Qt-Signale/Slots: Ist es ein Fehler, ein Signal von einem temporären Objekt zu senden?

Question

In Qt, wenn ein Signal von einem temporären Objekt aufgerufen wird, so dass das Objekt gelöscht werden kann, wenn der Slot aufgerufen wird, ist es ein Fehler?

Falls relevant, gibt der Code das Signal vom Konstruktor des temporären Objekts aus.

(Anmerkung: Da es keine Zeiger oder Referenzen gibt, die als Argument übergeben werden, handelt es sich also nicht um Fragezeichen oder Referenzen. Ich möchte nur wissen, ob es in seiner einfachsten Form akzeptabel ist, ein Signal zu senden . von einem temporären Objekt in Qt)

Hier ist eine verkürzte Version von meinem Code:

// My application 
class HandyApplication: public QApplication 
{ 
    Q_OBJECT 
    public: 
     explicit HandyApplication(int argc, char * argv[]); 

    signals: 

    public slots: 
     void handySlot(std::string const msg); 

}; 

// Class that will be instantiated to a temporary object 
class Handy: public QObject 
{ 
    Q_OBJECT 

    public: 

     Handy() 
     { 
      QObject::connect(this, SIGNAL(handySignal(std::string const)), 
       QCoreApplication::instance(), 
       SLOT(handySlot(std::string const))); 

      emit handySignal("My Message"); 
     } 

    signals: 

     void handySignal(std::string const msg); 

}; 

// An unrelated function that may be called in another thread 
void myFunction() 
{ 
    Handy temporaryObject; // This constructor call will emit the signal "handySignal" above 
} 

Wie Sie das temporäre Objekt sendet das Signal von seinem Konstruktor sehen können, und wird dann sofort zerstört. Daher kann der Steckplatz aufgerufen werden, nachdem das Objekt, das das Signal gesendet hat, zerstört wird.

Ist das sicher, oder ist dies ein potenzielles Problem oder ein Fehler?

Answer 1

Was Sie angegeben haben, wäre ein direct connection vom Signal zum Steckplatz. Das bedeutet, dass Sie im Moment handySignal ausgeben, sollte es gehen und alle verbundenen Slots ausführen. Sobald alle Steckplätze (z. B. handySlot) zurückgekehrt sind, kehrt der Emitter zurück und endet mit dem Konstruktor.

Wenn Sie eine queued connection angeben würden, die verwendet würde, wenn es eine Verbindung von einem Signal in einem Thread zu einem Slot in einem anderen Thread wäre, würde die Anforderung in die auszuführende Ereignisschleife platziert.

Also würde ich sagen: Ja, es scheint in Ordnung, ein Signal von einem temporären Objekt zu emittieren, wenn Sie keine Referenzen weitergeben, die ungültig sind.

Das Beispiel scheint ein bisschen willkürlich, da ich nicht wirklich einen Punkt sehe, eine Verbindung im Konstruktor zu einem Signal herzustellen, das Sie dann aussenden, und das ist es. Sie können diesen Slot auch nur aufrufen, wenn Sie nicht erwarten, dass das Objekt in einem anderen Thread erstellt wird, den Sie nicht erwähnt haben.

Edit:

Gemäß dem Kommentar von @Kamil, sollte es, dass nicht angegeben ist, wenn ein Verbindungstyp, beachtet wird, dann ist die defailt mit einem Autoconnect sein, die die tatsächliche Art bedeutet, wird bestimmt ob der Ziel-Slot sich in einem anderen Thread befindet als der Absender. Ohne Threading würde dies einer DirectConnection gleichkommen. Mit Threading würde es eine QueuedConnection sein.

Answer 2

würde ich sagen, von einem temporären Objekt emittiert ist sicher, da QObject::destroyed „wird sofort emittiert, bevor das Objekt obj wird zerstört“ - Qt docs

So vermutlich von einem temporären Objekt ausgesandten Signale würden sicher und richtig sein.