Solved reply->deleteLater in slot conditions
-
I have a slot that I connected with
QNetworkAccessManager
and in that slot I have a few conditions that I made with the content of the request, in one of them I use thereturn
in order to stop the continuation of the slot so I was wondering, if I have a condition like this:if(something) { return; }
do I have to call
reply->deleteLater()
in each condition that returns?if(something) { reply->deleteLater(); return; } reply->deleteLater();
I know if might sound a silly question, but I really don't know if I need that.
-
The documentation of QNetworkAccessManager is very clear here:
Note: After the request has finished, it is the responsibility of the user to delete the QNetworkReply object at an appropriate time. Do not directly delete it inside the slot connected to finished(). You can use the deleteLater() function.See http://doc.qt.io/qt-5/qnetworkaccessmanager.html#details
-
I know that, but that is not my question here actually, but if I have multiple if conditions in my finished reply slot, if I do have to be calling
reply->deleteLater
in each condition that needs to return and stop the execution. Or I can callreply->deleteLater
right at the top once.Example :
-
@Mr-Gisa
https://stackoverflow.com/questions/4888189/how-delete-and-deletelater-works-with-regards-to-signals-and-slots-in-qtThe deleteLater adds an event that will be handled in the main loop when control gets there.
-
@JonB
That is also what i assume. event loop is busy with current function so it should be safe
to deleteLater at top since nothing will happened before function ends.
Im just wondering if it will work in all use cases/always. -
@mrjj
Well, the OP asked:Or I can call reply->deleteLater right at the top once.
[to cut down on his coding] So he can safely do that at the top instead of the bottom providing the slot code does not allow main event loop to run, if that's what he wants to do. But if there is a chance that, say, at a later date someone might alter that code it might be dangerous. There are probably some C++ contructs which allow a piece of code to be run on function return (e.g. some scoped destructor)? In C# or Python I'd probably wrap in a
try ... finally
... -
@JonB
Ok we have the same ideas about it then :)
one QApplication::processEvents to ruin it all ;)I suggested to use QScopedPointer with QScopedPointerDeleteLater
to be sure.