Signals / Intervals Qt: Is it an error to give out a signal from a temporary object?

In Qt, if a signal is called from a temporary object, so that the object can be deleted by the time the slot is called, is this an error?

In case it matters, the code emits a signal from a temporary constructor object.

(Note: pointers or links are not passed as an argument, so this is not a question of dangling pointers or links. I just want to know if the signal from a temporary object in Qt is in its simplest form.)

Here is a shortened version of my 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 } 

As you can see, a temporary object emits a signal from its constructor and is immediately destroyed. Therefore, the slot can be called AFTER the object that sent the signal is destroyed .

Is it safe, or is it a potential problem or error condition?

+6
source share
2 answers

What you specified will be a direct connection from the signal to the slot. This means that at the moment you emit handySignal , it must go and execute all connected slots. As soon as all slots (i.e. handySlot ) return, then the emitter will return and finish the constructor.

If you indicated the queue in the queue , as it would have been used, if it were a connection from a signal in one thread to a slot in another thread, the request will be placed in the event loop that must be executed.

So, I would say: Yes, it seems that a signal is being emitted from a temporary object if you do not miss links that will be invalid.

The example seems a bit arbitrary, since I really see no reason to create a connection in the constructor with the signal that you then emit, and here it is. You can simply name this slot, unless you expect the object to be created in another thread that you did not mention.

Edit:

According to @Kamil's comment, it should be noted that if the connection type is not specified, then defailt is an auto-connection, which means that the actual type will be determined by whether the target slot in a different thread than the sender. Without slicing, it would match DirectConnection. When using streaming, it will ultimately be a QueuedConnection.

+4
source

I would say emitting from a temporary object is safe, because QObject::destroyed "is emitted just before the obj is destroyed" - Qt docs

Thus, presumably the signals emitted from the temporary object would be safe and correct.

+1
source

Source: https://habr.com/ru/post/945310/


All Articles