HINWEIS: DER BEREITGESTELLTE CODE GIBT NUR DIE IDEE DER STRUKTUR DER ANWENDUNGprocessEvents und Memory Leak?
Ich habe eine Qt-Anwendung, die mit externer Hardware verbunden ist. Die Struktur ist so, dass die Klasse für die Schnittstelle mit der Hardware von QObject
erbt und mit der Haupt-GUI-Thread-Klasse zusammengesetzt ist. Sagen wir, die Klasse test.h ist, hier ist seine Beispielcode:
#ifndef TEST_H
#define TEST_H
#include <QLineEdit>
#include <QString>
#include <QTimer>
#include "ui_test.h"
#define TIMEOUT 100
class TestObj;
class TestApp:public QWidget, public Ui::mTestForm
{
Q_OBJECT
public:
TestApp(QWidget* parent=0);
QTimer* mTimer;
bool mWindowClosed;
TestObj* mObj;
public slots:
void UpdateText();
void Exit();
};
class TestObj:public QObject
{
Q_OBJECT
public:
TestObj();
void RandomTest();
};
#endif
-Code für test.cpp ist
#include "test.h"
TestApp::TestApp(QWidget* parent):QWidget(parent)
{
setupUi(this);
mObj = new TestObj();
mWindowClosed=false;
mLineEdit->setText("Hello");
mTimer=new QTimer();
mTimer->singleShot(1000,this,SLOT(UpdateText()));
connect(mExitButton,SIGNAL(clicked()),this, SLOT(Exit()));
}
void TestApp::UpdateText()
{
if(mWindowClosed)
{
//QApplication::processEvents();
return;
}
else
{
//QApplication::processEvents();
mObj->RandomTest();
mLineEdit->setText("Hi");
mTimer->singleShot(100,this,SLOT(UpdateText()));
}
}
void TestApp::Exit()
{
mWindowClosed=true;
}
Betrachten wir nun, dass TestObj
Klasse diejenige ist, verwendet, um mit der Hardware zu kommunizieren. Diese Klasse sendet drei mögliche Befehle (im eigentlichen Code ist das obige nur eine Beispielstruktur) mit unterschiedlichen Timeouts an die Hardware, daher haben wir einen Timer, der verwendet wird, wenn Befehle (implementiert als Funktionen) an die Hardware gesendet werden. Jeder von diesen hat einen processEvents
Eintrag, um irgendwelche Änderungen zu den Variablen in der Zwischenzeit zu identifizieren.
Das Problem ist, dass dieses Modul für einen stetigen Speicheranstieg während der Programmausführung verantwortlich ist.
Wenn ich die UpdateText()
Funktion im TestApp
Konstruktor auskommentieren, funktioniert die App gut.
Meine Vermutung ist, dass es wahrscheinlich zu Warteschlangen von Signalsteckplätzen kommt, aufgrund derer der Speicher zunimmt, weil viele GUI-Ereignisse stattfinden. Und da die Klasse nicht als separater Thread implementiert ist und mit dem Haupt-GUI-Thread clubbed ist. Es gibt eine kontinuierliche Aktualisierung des Hauptthreads.
Kann jemand einen Ausweg vorschlagen? Ich bin nicht berechtigt, das Design zu ändern, sonst hätte ich die Interface-Klasse als Thread implementiert. Wenn also eine Lösung mit dem aktuellen Entwurf vorgeschlagen werden kann, wäre dies vorteilhaft.
Warum sind Sie besorgt, dass es als Duplikat geschlossen wird? Nun, da du das gesagt hast, bin ich fast versucht, alle anderen Fragen zu durchsuchen, um zu sehen, ob es wirklich kein Duplikat ist ... –
Da es immer noch das häufigste Speicherleck ist denke ich: Du sicher, dass du es löschst alle Zeichenfolgen beim Aktualisieren? Genauer gesagt: Löschen Sie die alte Saite, bevor Sie die neue setzen? (Falls benötigt). Denke nicht, dass das wirklich das Problem ist, also kommentiere ich einfach :). – StampedeXV