Hallo Forum, ich bin Neueinsteiger in der C++ Programmierung und auch in QT. Im Moment arbeite ich an einem Programm, welches ich Problemlos kompilieren (keine Fehler, keine Warnings) und auch Problemlos ausführen kann. Das eigentliche Problem ist, das ich das folgende nicht einmal kategorisieren kann: Wenn ich nämlich in irgendeiner Klasse zB. eine neue zusätzliche Variable deklariere (auch ohne eigentliche Verwendung), hängt sich das Programm nach dem erstellen der GUI auf - der Prozess verbraucht sämtliche Prozessorleistung (25% bei Quadcore CPU) und das Fenster lässt sich ohne Gewalt nicht mehr schließen. Sprich das Programm hängt. Tu ich die Variable wieder raus, gehts wieder. An der Variable selbst liegts allerdings nicht, da der Fehler auch auftritt, wenn ich in der GUI ein QT-Objekt hinzufüge. Meine Analyse: Das Programm braucht mehr Speicher als es bekommt. Der Speicherverbrauch wird lt. Taskmanager übrigens nicht mehr. Ich habe das ganze Programm mal im GDB Debugger gestartet, welcher keinen Fehler meldet - da sich das Programm ja nicht mal von selbst verabschiedet. Sourcecode zu Posten hat in dem Fall keinen Sinn, da ich eigentlich keinen Compilerfehler habe und das Programm auch eher umfangreich ist. Wenn wer interesse hat mir zu helfen kann ich Ihm gerne den Sourcecode per Mail schicken. Danke, Mike Entwicklungsumgebung: QT4.5.1 / MinGW Das Problem tritt auf 2 verschiedenen Rechnern (beide XP Pro) auf
Ist die Klasse (inklusive der Variablen) zufällig in einer Header-File deklariert, welche von mehreren Quellcode-Files aus verwendet wird? Hast du in diesem Fall darauf geachtet, nach der Änderung alle diese Quellcode-Files neu zu kompilieren (z.B. durch Löschen der temporären Object-Files mit der Endung .o vor dem Kompilieren)? Wenn du das nicht tust, arbeiten die einzelnen Quellcode-Dateien mit unterschiedlichen Versionen der Klasse (die unterschiedlich groß sind), und dann kann praktisch alles passieren.
Hallo Niklas, vielen Dank für Deine Antwort! Ich habe immer make clean aufgerufen und jetzt nach deinem Ratschlag die alle Dateien sowie den Release und den Debug Ordner auch manuell gelöscht, sodass nur mehr die Cpp und h Dateien übrig waren (und das (Designer).ui). Dann qmake -project, qmake, make Leider brachte dies keine Änderung. Trotzdem Danke, Michael
Hallo Leute,
Habe den Fehler warscheinlich (zumindest gehts jetzt) gefunden..
Nachdem ich vom Kommandozeilenkompiler weg bin habe ich mir den
QTCreator installiert, dann ca. 5 beschissene Stunden lang den Source
importiert und die Einstellungen und das .pro File so angepasst um das
ganze lauffähig zu bekommen. Ich kannte die IDE einfach nicht...
Um dann zu sehen dass das Programm im QTCreator generell hängt. Super..
Naja, in meiner Not zurück zum Notebook wo noch die alte QT Umgebung
installiert ist. Super.. Programm läuft wieder.. Versuchshalber mal eine
Release Version erstellt -> Programm hängt, die Debug.exe Version geht
aber..
Notlösung: Als Releaseversion die Debug verwenden (extremst Dirty aber
geht).
Aber erst mal weiterarbeiten im Programm... Im Designer die Gui minimal
verändert (ein Objekt entfernt), neu kompiliert -> Programm hängt..
Was mir dann aber aufgefallen ist... Wenn das Programm hängt, sind im
Task Manager auf einmal zwei MainWindow'se angeführt....
Die Lösung: Im Main das Objekt dynamisch anlegen...
vorher: Miniterminal mt; mt.show();
jetzt:
int main( int argc, char* argv[]){
QApplication a(argc, argv);
Miniterminal *mt;
mt = new Miniterminal();
mt->show();
return a.exec();
}
Null Ahnnung wieso, aber funktional. Und siehe da: Jetzt klappts auch im
QT Creator..
Vielleicht kann das ja mal wer (ein Newbi in C++ und QT like me)
brauchen, darum hab ich die Lösung mal gepostet...
Mfg,
Mike
Aja.. Das mit der statischen Erzeugung habe ich damals so aus einem QT
Tutorial übernommen..
Wenn mir wer sagen kann warum das Problem auftritt, wäre ich Dankbar.
1 | int main( int argc, char* argv[]){ |
2 | QApplication a(argc, argv); |
3 | Miniterminal *mt; |
4 | mt = new Miniterminal(); |
5 | mt->show(); |
6 | return a.exec(); |
7 | }
|
Fehlt da nicht an und für sich ein delete mt? Oder macht das show() selber?
Michael D. schrieb:
> Die Lösung: Im Main das Objekt dynamisch anlegen...
Aber natürlich. So wird das Objekt auf dem Heap (im Freispeicher)
angelegt, und so gehört es sich auch. Das nächste Mal bitte gleich den
falschen Code posten ;-)
@Mark Brandis warum macht es in diesem Fall ein unterschied ob das object auf dem Stack oder auf dem Heap liegt?
Rufus t. Firefly schrieb: > Fehlt da nicht an und für sich ein delete mt? Oder macht das show() > selber? show() zeigt meines Wissens nach nur das Fenster (oder was es eben ist) an. Und delete, öh, an welcher Stelle? Der Destruktor wird aufgerufen wenn man das Fenster manuell schließt, oder im Dateimenü (sofern vorhanden) das Programm beendet
jep, das fehlt und ist mir auch bewusst.. Kommt noch. Musste aus Glückseligkeit mal posten gehen... Ich habe mal probehalber ein Neues GUI projekt im Creator erstellt.. Der machts auch dynamisch.. Und er fügt auch das delete gleich mit ein.. Lg, Mike
Peter schrieb: > @Mark Brandis > > warum macht es in diesem Fall ein unterschied ob das object auf dem > Stack oder auf dem Heap liegt? Man weiß dass es Probleme macht, also lässt man es ;-) Von http://www.linux-mag.com/ : "Before we go further, it is important to know that Qt widgets should be allocated on the heap (i.e., with the new operator). This also applies to many other Qt objects. This is due to the fact that Qt keeps a hierarchy of its objects, and when an object higher up in the hierarchy is deleted, all its dependent objects will be dynamically deleted as well. But this only happens if the dependent objects were created on the heap. You can still delete the dependent object manually, but you usually do not need to. Keep in mind that creating Qt widgets on the stack (as local variables) can lead to hard-to-debug crashes, so don’t do it." "You might notice that all three widgets are constructed on the heap, using new(). Furthermore, each widget is passed a pointer to its parent in its constructor, except for QVGroupBox, which is passed a NULL pointer, because it’s a top-level widget and does not have a parent within the application’s address space. In Qt’s object model, a parent widget takes ownership of the memory allocated by its children. Whenever a parent widget is destroyed, it releases the memory of all of its child widgets. Therefore, there are no corresponding calls to delete() for each of the calls to new() that instantiated the widgets. Here, the framework provides (limited) garbage collection. However, for parents to take control over the lifecycle of their child widgets like this (to adopt them), the child widgets must be constructed on the heap. If the child widgets were constructed on the stack, they would be destroyed whenever control left the current block, with catastrophic consequences for the application."
Hmm... Noch eine Frage, nachdem ich jetzt ja wieder unter QT Creator arbeite.. Dieser hat ja den Designer gleich mit eingebaut.. Wo liegt der Trick, damit auch das ui_header.h File erzeugt wird? Wenn ich qmake ausführe und dann das Projekt neu erstelle ist ihm das ziemlich wurscht.. Er inoriert die Änderungen im GUI verwendet die alte Version.. Danke, Mike EDIT. hat sich erledit. Danke
> Wo liegt der Trick, damit auch das ui_header.h File erzeugt wird?
Ich arbeite nicht mit dem Qt Creator, aber prinzipiell muß das ui-File
im project-File unter FORMS eingetragen sein.
Genial der Creator - Kein nerviges Einrichten mehr mit ner anderen IDE. Sowas find ich gut. SDK runterladen und gleich loslegen. Nicht Qt runterladen, IDE einrichten und nach 3 Stunden den Fehler finden warum es nicht geht... Wenn ich zum Compilieren das grüne Pfeilsymbol links unten in der Tool-Leiste klicke funktinieren bei mir zusammengeklickte Dialoge. qmake manuell zu nutzen hab ich hier noch nicht probiert. Der autogenerierte Source aus zusammengeklicktem wie ui_mainwindow.h (oder ähnlich: ui_xxx.h) wird nicht im Projekt angezeigt, muss man manuell im Ordner hinnavigieren, wenn man den Inhalt sehen will. Autocompletion bei neu hinzugetipptem wird erst erkannt, wenn vorcompiliert wurde. Genial auch das Suchfenster unten. ": qapp" + Enter bringt dich z.B. in die Definition von class QApplication; [Ich hab bisher noch kein VC++ benutzt, weil mir meist andere IDE empfohlen wurden. Cor Creator zuletzt: Code::Blocks ...]
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.