Ich arbeite an einem ziemlich Standard Qt Mobile App (geschrieben in C++, gezielt auf Symbian-Geräte), und finde das manchmal, wenn die App geschlossen ist (zB über einen Anruf an QApplication :: quit), kann der endgültige Destruktor in der App lange dauern (30 Sekunden plus). Damit meine ich, dass alle Bereinigungsoperationen im Destruktor abgeschlossen sind (schnell, alles innerhalb einer Sekunde) und wir haben den Punkt erreicht, an dem Ausführung den Destruktor verlässt und zu dem Code zurückkehrt, der ihn implizit aufgerufen hat (dh wenn wir löschen das Objekt).Qt C++ Destruktor dauert eine lange Zeit bis
Offensichtlich würde ich erwarten, dass die Ausführung direkt nach dem Aufruf zurückkehrt, um das Objekt praktisch sofort zu löschen, aber wie ich manchmal sage, dauert das ein Alter!
Diese lange Schließzeit tritt sowohl bei Debug- als auch bei Release-Builds auf, wenn die Protokollierung aktiviert oder deaktiviert ist. Daher glaube ich nicht, dass dies ein Faktor ist. Wenn wir das Ende des Destruktors erreicht haben, bin ich ziemlich sicher, dass keine Dateigriffe offen bleiben, oder irgendwelche anderen offenen Ressourcen (Netzwerkverbindungen etc.) ... obwohl selbst wenn sie sich dort nicht als Problem darstellen würden Beenden des Destruktors (?).
Dies ist beim Löschen des QMainWindow-Objekts der Anwendung. Momentan ist der Aufruf dazu in einem Slot, der mit QApplication :: aboutToQuit verbunden ist, obwohl ich versucht habe, dieses Objekt auch in der "Haupt" -Funktion der Apps zu löschen.
Die Länge der Verzögerung, die wir erleben, scheint proportional zum Umfang der Aktivität in der App zu sein, bevor wir sie verlassen. Diese Art von macht mich denken, dass Speicherlecks ein Problem hier sein können, aber wir sind uns keiner bewusst (bedeutet nicht, dass sind nicht natürlich), und auch ich habe dieses Verhalten noch nie mit durchgesickert gesehen Erinnerung.
Hat jemand irgendwelche Ideen, was hier los sein könnte?
Prost
Tritt dieses Problem auf, wenn Sie auch einen Debugger verwenden? Können Sie die Zeile (n) des Codes isolieren, die so lange dauern? –
Ja, ich sehe das auch im Debugger. In Bezug auf die Isolierung, welche Segmente des Codes zu lange dauern, besteht das Problem darin, dass die Verzögerung auftritt, während man vom Destruktor selbst zurückkehrt. Die letzte Zeile des Destruktors wurde also beendet, und wir treten aus dem Destruktor aus, und zu diesem Zeitpunkt tritt die Verzögerung ein. Ich glaube, das Qt-Framework tut etwas an diesem Punkt, was die Verzögerung verursacht, obwohl ich noch nicht weiß, was. – busta83