Moin,
ich habe hier mal ne Frage an die Qt Experten: warum sind Widgets nicht sichtbar, die als Objekt definiert wurden, wohingegen mittels des new Operators erzeugte Widgets sichtbar sind? Ein meinWidget.show() habe ich natürlich auch gesagt - ohne Erfolg. Im Tutorial ist gleich im ersten Beispiel der Fall dabei, wo ein Widget so instanziiert wurde:
QPushButton hello( "Hello world!", 0 );
das geht auch. Innerhalb meiner Klasse geht es aber nicht, Ideen warum das so ist?
andre
On Wed, Dec 05, 2001 at 08:13:43PM +0100, Andre Schulze wrote:
Moin,
ich habe hier mal ne Frage an die Qt Experten: warum sind Widgets nicht sichtbar, die als Objekt definiert wurden, wohingegen mittels des new Operators erzeugte Widgets sichtbar sind?
Nicht generell... Eigentlich muss jedes QWidget mittels der Methode 'show()' sichtbar gemacht werden. Wenn du ein Programm schreibst mit einem Object QApplication, weist du ihm ein MainWidget:
QApplication app;
QWidget wdg("toplevel", 0); wdg.show();
app.setMainWidget(&wdg);
Wenn du jetzt ein anderes Widget auf unser gerade erzeugtes Widget draufpappen möchtest, allozierst du es normalerweise mit 'new', gibst im Konstruktor aber einen Pointer auf das Elternobjekt mit:
QWidget *childWidget = new QWidget("child", &wdg);
Das Elternobjekt ruft nun automagisch die show()-Methode all seiner Kinder auf.
Ciao, Tobias
On Wednesday 05 December 2001 07:16, Tobias Koenig wrote:
app.setMainWidget(&wdg);
Darf ich mal anmerken daß es bei KApplication setMainWidget heißt, bei QApplication aber setCentralWidget? :-)
Das Elternobjekt ruft nun automagisch die show()-Methode all seiner Kinder auf.
Wobei es etliche Widgets wie das OpenGL-Teil oder auch QSplitter gibt, die so ihre eigenen Vorstellungen vom Weltbild haben... aber das findet man schon raus, wenn plötzlich alles verschoben und komisch aussieht.
Noch ein Tip: Qt-Objekte, die ein anderes QObject als Parameter bekommen (also z.B. ein "this"), braucht man im Konstruktor nicht zu löschen, weil das schon die Garbage Collection für einen macht. [Java-Programmierer schlagt mich bitte, aber so in etwa funktioniert das schon.]
Josef
Am Donnerstag, dem 06. Dezember 2001 um 08:57:01, schrieb Josef Spillner:
Noch ein Tip: Qt-Objekte, die ein anderes QObject als Parameter bekommen (also z.B. ein "this"), braucht man im Konstruktor nicht zu löschen, weil das schon die Garbage Collection für einen macht.
Wieso sollte man Objekte im Konstruktor loeschen wollen? Ausserdem halte ich deine Aussage zur Garbage Collection in dieser Form fuer Quatsch - wie soll das denn funktionieren? Was ist, wenn das Objekt selbst gar nicht dynamisch alloziert wurde?
Torsten
On Thu, Dec 06, 2001 at 10:21:58AM +0100, Torsten Werner wrote:
Am Donnerstag, dem 06. Dezember 2001 um 08:57:01, schrieb Josef Spillner:
Noch ein Tip: Qt-Objekte, die ein anderes QObject als Parameter bekommen (also z.B. ein "this"), braucht man im Konstruktor nicht zu löschen, weil das schon die Garbage Collection für einen macht.
Wieso sollte man Objekte im Konstruktor loeschen wollen? Ausserdem halte
Der Destruktor war sicherlich gemeint.
ich deine Aussage zur Garbage Collection in dieser Form fuer Quatsch - wie soll das denn funktionieren? Was ist, wenn das Objekt selbst gar nicht dynamisch alloziert wurde?
Dann platzt die Library vor Wut. Oder es verfault die Segmentation.
Heiko
Am Donnerstag, dem 06. Dezember 2001 um 10:28:27, schrieb Heiko Schlittermann:
Dann platzt die Library vor Wut. Oder es verfault die Segmentation.
Womit sich meine Vorurteile gegen qt wieder mal bestaetigen: Man kann auf einfache Art huebsche GUIs erstellen, aber es ist irgendwie doch kein C++ (fehlende Namensraeume, Ausnahmen, typsicherer und in der Sprache selbst implementierter Signal-Slot-Mechanismus, Zusammenarbeit mit der Standardbibliothek...)
Torsten
On Thu, Dec 06, 2001 at 10:39:53AM +0100, Torsten Werner wrote:
Am Donnerstag, dem 06. Dezember 2001 um 10:28:27, schrieb Heiko Schlittermann:
Dann platzt die Library vor Wut. Oder es verfault die Segmentation.
Womit sich meine Vorurteile gegen qt wieder mal bestaetigen: Man kann auf einfache Art huebsche GUIs erstellen, aber es ist irgendwie doch kein C++ (fehlende Namensraeume
Wiso einen extra Namensraum, wenn alle relevanten Klassennamen mit 'Q' beginnen?
, Ausnahmen
welche?
Sprache selbst implementierter Signal-Slot-Mechanismus,
... was ich als Designfehler von C++ und nicht von Qt sehen würde...
Zusammenarbeit mit der Standardbibliothek...)
man könnte freilich eine extra SignalSlot-Bibliothek dazulinken, aber das wäre eine Abhängigkeit mehr... Warum also nicht selbst implementieren und an das ToolKit gleich anpassen?
P.S. du hattest die <FLAME>-Tags vergessen ;)
Ciao, Tobias
Am Donnerstag 06 Dezember 2001 07:00 schrieben Sie:
On Thu, Dec 06, 2001 at 10:39:53AM +0100, Torsten Werner wrote:
Womit sich meine Vorurteile gegen qt wieder mal bestaetigen: Man kann auf einfache Art huebsche GUIs erstellen, aber es ist irgendwie doch kein C++ (fehlende Namensraeume
Wiso einen extra Namensraum, wenn alle relevanten Klassennamen mit 'Q' beginnen?
Nun, wenn etwas wie ein Typ, Variable oder Funktion genauso heißt wie etwas in den, sagen wir, X-Headerfiles die du zufällig auch einbinden musst, hast du einen Namenskonflikt, und der Compiler weiß nicht was er nehmen soll bzw. nimmt das falsche. Namensräume würden bei soetwas helfen.
Sprache selbst implementierter Signal-Slot-Mechanismus,
... was ich als Designfehler von C++ und nicht von Qt sehen würde...
Na klar, jede moderne Programmiersprache hat ja den Signal-Slot-Mechanismus, nur C++ nicht.
Stephan
Am Freitag, dem 07. Dezember 2001 um 04:03:05, schrieb Stephan Goetter:
Am Donnerstag 06 Dezember 2001 07:00 schrieben Sie:
On Thu, Dec 06, 2001 at 10:39:53AM +0100, Torsten Werner wrote:
Sprache selbst implementierter Signal-Slot-Mechanismus,
... was ich als Designfehler von C++ und nicht von Qt sehen würde...
Na klar, jede moderne Programmiersprache hat ja den Signal-Slot-Mechanismus, nur C++ nicht.
http://libsigc.sourceforge.net/
schon Jahre alt, typsicher, schnell und in der Sprache C++ selbst implementiert.
Torsten
Am Freitag 07 Dezember 2001 08:52 schrieben Sie:
Am Freitag, dem 07. Dezember 2001 um 04:03:05, schrieb Stephan Goetter:
Am Donnerstag 06 Dezember 2001 07:00 schrieben Sie:
On Thu, Dec 06, 2001 at 10:39:53AM +0100, Torsten Werner wrote:
Sprache selbst implementierter Signal-Slot-Mechanismus,
... was ich als Designfehler von C++ und nicht von Qt sehen würde...
Na klar, jede moderne Programmiersprache hat ja den Signal-Slot-Mechanismus, nur C++ nicht.
Falls ich <SARCASM> vergessen haben sollte tut mir das leid.
http://libsigc.sourceforge.net/
schon Jahre alt, typsicher, schnell und in der Sprache C++ selbst implementiert.
Hab mich schon gefragt was diese Library macht.
Puh, brauch ich mir also bald doch kein neues C++-Buch kaufen, welches dann die Signal-Slot-C++-Spracherweiterung enthält.
Stephan
Am Donnerstag 06 Dezember 2001 10:39 schrieben Sie:
Am Donnerstag, dem 06. Dezember 2001 um 10:28:27, schrieb Heiko
Schlittermann:
Dann platzt die Library vor Wut. Oder es verfault die Segmentation.
Das hat sich ja nun Glücklicherweise nicht bestätigt.
Womit sich meine Vorurteile gegen qt wieder mal bestaetigen: Man kann auf einfache Art huebsche GUIs erstellen, aber es ist irgendwie doch kein C++ (fehlende Namensraeume, Ausnahmen, typsicherer und in der Sprache selbst implementierter Signal-Slot-Mechanismus, Zusammenarbeit mit der Standardbibliothek...)
Nun, zumindest den Namensraum Qt gibt es ja schon ;)
GUIs müssen heute nicht nur hübsch sein, sondern auch effizient. Ich erinnere da an die xx Millisekunden die eine GUI maximal warten sollte. Jetzt schau dir die Performanceprobleme bei KDE an, und worauf die Zurückzuführen sind. Voll und ganz nur auf C++. Nun stell dir vor, die hätten in Qt noch Ausnahmen verwendet (allgemein bekannt für ihre Performance) und was C++ nicht alles noch bietet. Die Zusammenarbeit mit der Standardbibliothek ist da schon ein Punkt wo ich dir recht gebe, weil so der gleiche Code nur doppelt und dreifach im Speicher rumdümpelt. Bibliotheken sind wirklich gut, aber wenn jedes Programm seine eigenen hat ist das wider dem Konzept.
Ein kürzlicher Blick in die KDE-Sourcen und wieviel Stringvergleiche da in der Ereignisroutine gemacht wurden (if event.object->inherits("KComboBox")) hat mir dann übriges gesagt. So kommt man auf keinen grünen Zweig und an die Performance der C-GUI unter Windows auf lange Sicht nicht heran.
Gruß, Stephan
On Thu, Dec 06, 2001 at 03:32:17PM +0100, Stephan Goetter wrote:
Ein kürzlicher Blick in die KDE-Sourcen und wieviel Stringvergleiche da in der Ereignisroutine gemacht wurden (if event.object->inherits("KComboBox")) hat mir dann übriges gesagt. So kommt man auf keinen grünen Zweig und an die Performance der C-GUI unter Windows auf lange Sicht nicht heran.
C-GUI? Wo nimmst Du diese Weisheit her? Unten drunter ist C (bei KDE ja auch -> xlib) aber oben drüber wird heutzutage alles mit Gigantischen Klassenbibiliotheken gemacht. Einziger Vorzug: für gewisse Dinge wie Strings, gibt es eingene Klassen, da die STL-Kontainer einfach mal scheiße lahm sind (wegen ihrer eigenschaft als generische Klassen). Ansonsten sind viele spezielle Controls (=Widgets) aber sogar in VisualBasic geschrieben.
habichmichjetztgeoutet? Eric
Am Donnerstag 06 Dezember 2001 16:22 schrieben Sie:
On Thu, Dec 06, 2001 at 03:32:17PM +0100, Stephan Goetter wrote: C-GUI? Wo nimmst Du diese Weisheit her? Unten drunter ist C (bei KDE ja auch -> xlib) aber oben drüber wird heutzutage alles mit Gigantischen Klassenbibiliotheken gemacht.
Als ich noch unter Windows mit C programmiert habe (vor 10 Jahren?) war das noch so :)
Einziger Vorzug: für gewisse Dinge wie Strings, gibt es eingene Klassen, da die STL-Kontainer einfach mal scheiße lahm sind (wegen ihrer eigenschaft als generische Klassen).
Nun, dann stellt sich die Frage warum Windows doch intuitiv bei Schaltern und Comboboxen schneller ist als Qt&Co., GTK+ mal ausgenommen.
Ansonsten sind viele spezielle Controls (=Widgets) aber sogar in VisualBasic geschrieben.
habichmichjetztgeoutet?
Muss dir nicht peinlich sein.
Stephan
On Thu, Dec 06, 2001 at 04:48:51PM +0100, Stephan Goetter wrote:
Am Donnerstag 06 Dezember 2001 16:22 schrieben Sie:
On Thu, Dec 06, 2001 at 03:32:17PM +0100, Stephan Goetter wrote: C-GUI? Wo nimmst Du diese Weisheit her? Unten drunter ist C (bei KDE ja auch -> xlib) aber oben drüber wird heutzutage alles mit Gigantischen Klassenbibiliotheken gemacht.
Als ich noch unter Windows mit C programmiert habe (vor 10 Jahren?) war das noch so :)
Na vor 10 Jahren ... (gabs auch noch kein qt & Co.)
Einziger Vorzug: für gewisse Dinge wie Strings, gibt es eingene Klassen, da die STL-Kontainer einfach mal scheiße lahm sind (wegen ihrer eigenschaft als generische Klassen).
Nun, dann stellt sich die Frage warum Windows doch intuitiv bei Schaltern und Comboboxen schneller ist als Qt&Co., GTK+ mal ausgenommen.
Die sind sicher nicht in VB gebaut. Außerdem ist sicher Windows an sich schon schneller als X (architekturell bedingt) Hab von beiden noch keinen Quellcode gesehen, kann also keine genauer Aussage machen. Fakt ist, daß Windows genauso wie X wesentlich schneller sind, wenn man nur die einfachen C-Bindings benutzt, statt irgendwelcher aufgeblähter Klassenbibiliotheken. Man kann das sicher auch schlecht vergleichen (schon auf Atari und Amiga gab es sehr schnelle GUIs, die wurden aber oft sogar nur in Assembler angesprochen. Speziell auf dem Amiga gab es auch prima Multitasking und ein recht brauchbares Messagesystem. Nur leider keine MMU.)
Gruß, Eric
On Thursday 06 December 2001 16:22, Eric Schaefer wrote:
C-GUI? Wo nimmst Du diese Weisheit her? Unten drunter ist C (bei KDE ja auch -> xlib) aber oben drüber wird
<nitpick> $KDECVS/kdenox </nitpick>
Ich denke auch, daß mit dem Boom von SVG solche Sachen wie Berlin (nein, nicht die Stadt) an Bedeutung gewinnen werden.
Josef Spillner
On Thursday 06 December 2001 10:39, Torsten Werner wrote:
Womit sich meine Vorurteile gegen qt wieder mal bestaetigen: Man kann auf einfache Art huebsche GUIs erstellen, aber es ist irgendwie doch kein C++ (fehlende Namensraeume, Ausnahmen, typsicherer und in der Sprache selbst implementierter Signal-Slot-Mechanismus, Zusammenarbeit mit der Standardbibliothek...)
STL: ist mit Qt 3 weitgehend behoben (z.B. QList::size statt QList::count).
Signals und Slots: Trolltech hat einen Antrag auf Aufnahme in den C++-Standard gestellt (siehe Interview auf dot.kde.org mit deren Präsidenten vor ein paar Wochen), alles andere liegt jetzt wohl bei dem Konsortium oder was auch immer darüber entscheidet.
Die Typsicherheit wirst du so schnell nicht bekommen können, was die aktuellen Diskussionen darüber auch zeigen, vor allem das Verhalten von diversen *_cast-Operatoren auf nicht-Linux-Plattformen. (Was doch sicher mit dazugehört)
Exceptions: Es gab da eine laaaaange Diskussion, u.a. über die Performance, allerdings war das KDE-spezifisch. Wie das bei Qt ist kann ich leider nicht sagen.
Namespaces: Sind IMO sauber implementiert, es gibt aber z.B. Probleme mit eingebundenen C-Bibliotheken, z.B. Mesa3D (QGLWidget) definiert DisplayList, und ein in den Browser einzubindendes proprietäres buntes lautes Plugin einer Firma namens Macromedia tut das auch.... es soll Nutzer geben die dann damit Probleme haben.
Josef Spillner
On Thursday 06 December 2001 10:21, Torsten Werner wrote:
Wieso sollte man Objekte im Konstruktor loeschen wollen? Ausserdem halte ich deine Aussage zur Garbage Collection in dieser Form fuer Quatsch - wie soll das denn funktionieren? Was ist, wenn das Objekt selbst gar nicht dynamisch alloziert wurde?
Ts, da verwechselt man Kon mit De (es war früh am Morgen...), und schon wird ein richtig schöner Flamewar draus :)
Bei Objekten in Qt unterscheidet man zwischen implizierter und expliziter Teilung eines Objektes unter den anderen. Also wenn mein Widget A jetzt ein Widget B herstellt, und A wird gelöscht, tja dann gibt es A auch nicht mehr. Das läßt sich ganz einfach dadurch realisieren, daß jedes Kindobjekt sich beim Parent registriert, und im Destruktor (ha, jetzt stimmts) sich wieder aus der Registriertabelle löschen läßt. Wenn jetzt A gelöscht wird und B noch drin steht, wird B mit "entsorgt".
Bei mir unter: file:/usr/local/qt/doc/html/shclass.html Oder auch: "The parent receives object ownership, i.e. it will automatically delete its children in its destructor." (QObject)
Sicher kein sehr toller Ansatz, aber sowohl für Qt als auch Gtk+ sind die Bindings "richtiger" objektorientierter Sprachen wie Ruby noch nicht so weit. Ich habe mal versucht ein Ruby-Spiel zu erstellen mit Qt, irgendwie kamen die Events nicht richtig an :( (Mal abgesehen daß das nur ein API-Wrapper ist, aber eine native Implementierung würde mehr Manpower in Anspruch nehmen als im Moment da ist... das ist mit den Python-Bindings etc. auch nicht anders...)
Josef Spillner
On Thu, Dec 06, 2001 at 08:57:01AM +0100, Josef Spillner wrote:
On Wednesday 05 December 2001 07:16, Tobias Koenig wrote:
app.setMainWidget(&wdg);
Darf ich mal anmerken daß es bei KApplication setMainWidget heißt, bei QApplication aber setCentralWidget? :-)
Darf ich mal anmerken, daß es bei QApplication dennoch setMainWidget heißt und setCentralWidget bei QMainWindow definiert ist ;)
<schnipp> P.S. Kann es sein, das mailman ein kleines Problem mit dem senden der Mails in der richtigen Reihenfolge hat? Ich hatte bereits 2 Antworten auf diese Mail erhalten... Liegt das nun an meinen pop3-Account oder an mailman?
Ciao, Tobias
Am Wed den 05 Dec 2001 um 07:16:55AM +0100 schrieb Tobias Koenig:
On Wed, Dec 05, 2001 at 08:13:43PM +0100, Andre Schulze wrote:
Moin,
ich habe hier mal ne Frage an die Qt Experten: warum sind Widgets nicht sichtbar, die als Objekt definiert wurden, wohingegen mittels des new Operators erzeugte Widgets sichtbar sind?
Tobias:
Nicht generell... Eigentlich muss jedes QWidget mittels der Methode 'show()' sichtbar gemacht werden. Wenn du ein Programm schreibst mit einem Object QApplication, weist du ihm ein MainWidget:
QApplication app;
QWidget wdg("toplevel", 0); wdg.show();
app.setMainWidget(&wdg);
int main(int argc, char *argv[]) { QApplication a(argc, argv); a.setFont(QFont("helvetica", 6)); // dies ist die Klasse, in der die Widgets nicht hochkommen wollen: // name ist leer, und es ist das top-level widget QteMUA *qtemua=new QteMUA(0,0);
// das MainWidget sorgt in erster Linie dafür, daß das a.exec() //zurückkehrt, wenn das Widget zerstört wird.
a.setMainWidget(qtemua);
// laut Doku sollte ein show() des Parent Widgets dafür sorgen, daß //die Kinders auch gekritzelt werden, vielleicht stimmen die //Familienverhältnisse bei mir ja nicht... qtemua->show();
return a.exec(); }
Wenn du jetzt ein anderes Widget auf unser gerade erzeugtes Widget draufpappen möchtest, allozierst du es normalerweise mit 'new', gibst im Konstruktor aber einen Pointer auf das Elternobjekt mit:
QWidget *childWidget = new QWidget("child", &wdg);
Das Elternobjekt ruft nun automagisch die show()-Methode all seiner Kinder auf.
So habe ich es auch verstanden und so funzt es ja auch.
Am Thu den 06 Dec 2001 um 08:57:01AM +0100 schrieb Josef Spillner:
On Wednesday 05 December 2001 07:16, Tobias Koenig wrote:
app.setMainWidget(&wdg);
Josef:
Darf ich mal anmerken daß es bei KApplication setMainWidget heißt, bei QApplication aber setCentralWidget? :-)
Es ist glaube ich genau anders herum.
Am Thu den 06 Dec 2001 um 10:21:58AM +0100 schrieb Torsten Werner:
Am Donnerstag, dem 06. Dezember 2001 um 08:57:01, schrieb Josef Spillner:
Noch ein Tip: Qt-Objekte, die ein anderes QObject als Parameter bekommen (also z.B. ein "this"), braucht man im Konstruktor nicht zu löschen, weil das schon die Garbage Collection für einen macht.
Thorsten:
Wieso sollte man Objekte im Konstruktor loeschen wollen? Ausserdem halte
Ist wohl ein Tipfehler... .
ich deine Aussage zur Garbage Collection in dieser Form fuer Quatsch - wie soll das denn funktionieren? Was ist, wenn das Objekt selbst gar nicht dynamisch alloziert wurde?
Josef hat es wahrscheinlich nur etwas unglücklich formuliert. Da ja die GUI idR immer von QWidget abgeleitet ist, erbt man auch dessen Destruktor mit und wenn man den nicht überlädt, dann ruft der die Destruktoren der Child Widgets mit auf. So steht es ungefähr in der Doku:
QWidget::~QWidget()
Destructs the widget.
All children of this widget are deleted first. The application exits if this widget is (was) the main widget.
Mit Garbage Collection hat das aber nichts zu tun. AFAIK ist das in Java ein eigener Thread, der in der VM implementiert ist.
Am Wed den 05 Dec 2001 um 10:01:31PM +0100 schrieb Torsten Werner:
Tutorial ist gleich im ersten Beispiel der Fall dabei, wo ein Widget so instanziiert wurde:
QPushButton hello( "Hello world!", 0 );
Der Blick in die Glaskugel sagt mir, dass du eigentlich ein
QPushButton hello( "Hello world!", this);
willst. Um mehr zu sagen, braeuchte man Beispielquellen.
Innerhalb der Klasse habe ich auch this anstatt 0 (==top_level) verwendet.
Nun ich wollte die Liste nicht mit Code überschwemmen, in der o.g. Klasse QteMUA sieht es also wie folgt aus:
QteMUA::QteMUA( QWidget *parent, const char *name ) : QWidget( parent, name ) { // als Objekt definiert: // this ist parent (FALSE sagt lediglich, dass es readonly ist) QComboBox boxFolders(FALSE,this,"Folders"); // so würde es angezeigt werden (wenn man unten dann // boxFolders.(methode) durch boxFolders->(methode) ersetzen // würde natürlich
//boxFolders = new QComboBox ( FALSE, this, "Folders" ); boxFolders.setGeometry(0,0,80,20); boxFolders.insertItem ( (QString) "Inbox", Inbox ); boxFolders.show();
So bleibt es aber dunkel.
andre
Am Donnerstag, dem 06. Dezember 2001 um 12:37:35, schrieb Andre Schulze:
QteMUA::QteMUA( QWidget *parent, const char *name ) : QWidget( parent, name ) { // als Objekt definiert: // this ist parent (FALSE sagt lediglich, dass es readonly ist) QComboBox boxFolders(FALSE,this,"Folders");
// so würde es angezeigt werden (wenn man unten dann // boxFolders.(methode) durch boxFolders->(methode) ersetzen // würde natürlich
//boxFolders = new QComboBox ( FALSE, this, "Folders" ); boxFolders.setGeometry(0,0,80,20); boxFolders.insertItem ( (QString) "Inbox", Inbox ); boxFolders.show();
So bleibt es aber dunkel.
Interessant waere noch der Fall
QComboBox& boxFolders = *new QComboBox ( FALSE, this, "Folders" );
usw. Aber es ist schon sehr seltsam und ich vermute den Bug an ganz anderer Stelle.
Torsten
Am Donnerstag 06 Dezember 2001 12:37 schrieben Sie:
Am Wed den 05 Dec 2001 um 07:16:55AM +0100 schrieb Tobias Koenig:
On Wed, Dec 05, 2001 at 08:13:43PM +0100, Andre Schulze wrote:
QteMUA::QteMUA( QWidget *parent, const char *name )
: QWidget( parent, name ){ // als Objekt definiert: // this ist parent (FALSE sagt lediglich, dass es readonly ist) QComboBox boxFolders(FALSE,this,"Folders");
// so würde es angezeigt werden (wenn man unten dann // boxFolders.(methode) durch boxFolders->(methode) ersetzen // würde natürlich
//boxFolders = new QComboBox ( FALSE, this, "Folders" ); boxFolders.setGeometry(0,0,80,20); boxFolders.insertItem ( (QString) "Inbox", Inbox ); boxFolders.show();
So bleibt es aber dunkel.
Was passiert eigentlich mit lokalen Variablen am Kontruktorende?
Stephan
Am Donnerstag, dem 06. Dezember 2001 um 15:05:34, schrieb Stephan Goetter:
Was passiert eigentlich mit lokalen Variablen am Kontruktorende?
Na wenigstens einer guckt scharf hin.
Am Donnerstag, dem 06. Dezember 2001 um 15:32:17, schrieb Stephan Goetter:
Nun, zumindest den Namensraum Qt gibt es ja schon ;)
Wo? In neueren Versionen als 2.3?
Nun stell dir vor, die hätten in Qt noch Ausnahmen verwendet (allgemein bekannt für ihre Performance) und was C++ nicht alles noch bietet.
Ich war immer der Meinung, dass Ausnahmen im Normalfall (kein Fehler aufgetreten) keinen Performancenachteil darstellen. Und im Fehlerfall braucht man sowieso irgendeine Art von Fehlerbehandlung. Hast du da andere Informationen, Zahlen etc.?
Ein kürzlicher Blick in die KDE-Sourcen und wieviel Stringvergleiche da in der Ereignisroutine gemacht wurden (if event.object->inherits("KComboBox")) hat mir dann übriges gesagt.
Zustimmung, das ist beim Signal-Slot-Konzept genauso. Aber ob das wirklich das entscheidende Performance-Problem ist?
Torsten
Am Donnerstag 06 Dezember 2001 15:45 schrieben Sie:
Am Donnerstag, dem 06. Dezember 2001 um 15:05:34, schrieb Stephan Goetter:
Was passiert eigentlich mit lokalen Variablen am Kontruktorende?
Na wenigstens einer guckt scharf hin.
Am Donnerstag, dem 06. Dezember 2001 um 15:32:17, schrieb Stephan Goetter:
Nun, zumindest den Namensraum Qt gibt es ja schon ;)
Wo? In neueren Versionen als 2.3?
http://doc.trolltech.com/2.3/qnamespace-h.html
Nun stell dir vor, die hätten in Qt noch Ausnahmen verwendet (allgemein bekannt für ihre Performance) und was C++ nicht alles noch bietet.
Ich war immer der Meinung, dass Ausnahmen im Normalfall (kein Fehler aufgetreten) keinen Performancenachteil darstellen. Und im Fehlerfall braucht man sowieso irgendeine Art von Fehlerbehandlung. Hast du da andere Informationen, Zahlen etc.?
Zahlen gibts bestimmt im Netz. Im Bjarne Stroustrup gibts ein extra Kapitel "14.8 Ausnahmen und Effizienz":
"Prinzipiell kann Ausnahmebehandlung so implementiert werden, daß kein Mehraufwand zu Laufzeit auftritt, wenn keine Ausnahme geworfen wird. Zusätzlich kann das Werfen so realisiert werden, daß es nicht viel aufwendiger als ein normaler Funktionsaufruf ist. Dies zu tun, ohne erheblichen Mehraufwand an Speicher zuzufügen und gleichzeitig die Kompatibilät mit der C-Aufrufschnittstelle, mit Debugger-Konventionen, usw. zu wahren ist möglich, aber schwer. Allerdings muss man in Errinnerung behalten, daß die Alternativen zur Ausnahmebehandlung auch nicht umsonst sind. Es ist nicht unüblich, daß sich in traditionellen Systemen die Hälfte des Codes mit Fehlerbehandlung beschäftigt."
Hier klingt er wie ein Politiker der sich für seine Amtszeit rechtfertigt ;) und beantwortet die Frage ob ein "return -1;" schneller ist als ein "throw Exception();" eigentlich von selbst.
Das die Implementation des g++ unter Linux solch eine wie die oben beschriebene ist, bezweifle ich stark und bestätigen mir eigentlich die ständigen Forderungen der KDE-Entwickler an das gcc-Team. Mal ganz abgesehen von der Dauer des Compilierens eines C++-Programms im Vergleich zu einem C-Programm.
Ein kürzlicher Blick in die KDE-Sourcen und wieviel Stringvergleiche da in der Ereignisroutine gemacht wurden (if event.object->inherits("KComboBox")) hat mir dann übriges gesagt.
Zustimmung, das ist beim Signal-Slot-Konzept genauso.
Da wird auch ein Stringvergleich gemacht? Ich dachte das man da nur einen Methodenaufruf als Overhead hat.
Aber ob das wirklich das entscheidende Performance-Problem ist?
Nein, sicher nicht. Hier gilt denke ich Kleinvieh macht auch Mist, das sind aber bestimmt nur die Spitzen vom Eisberg, wie so oft.
Stephan
On Thursday 06 December 2001 12:37, Andre Schulze wrote:
Josef:
Darf ich mal anmerken daß es bei KApplication setMainWidget heißt, bei QApplication aber setCentralWidget? :-)
Es ist glaube ich genau anders herum.
Asche auf mein Haupt - ich war schon einen Schritt weiter in MainWindow, wo es nicht mehr setMainWidget sondern setCentralWidget heißt. Ganz konfus wird es, wenn man alte KDE 1.x-Apps portiert, bei denen heißt selbiges dann setView :)
Mit Garbage Collection hat das aber nichts zu tun. AFAIK ist das in Java ein eigener Thread, der in der VM implementiert ist.
Deswegen war das auch in eckigen Klammern, werde nächstes Mal wohl Ironie-Tags verwenden. Für den Programmierer kommt dasselbe raus: Kein "delete" auf registrierte QObjects machen.
Josef Spillner
On Thu, Dec 06, 2001 at 12:37:35PM +0100, Andre Schulze wrote:
Am Wed den 05 Dec 2001 um 07:16:55AM +0100 schrieb Tobias Koenig:
On Wed, Dec 05, 2001 at 08:13:43PM +0100, Andre Schulze wrote:
Moin,
ich habe hier mal ne Frage an die Qt Experten: warum sind Widgets nicht sichtbar, die als Objekt definiert wurden, wohingegen mittels des new Operators erzeugte Widgets sichtbar sind?
<schnipp>
Innerhalb der Klasse habe ich auch this anstatt 0 (==top_level) verwendet.
Nun ich wollte die Liste nicht mit Code überschwemmen, in der o.g. Klasse QteMUA sieht es also wie folgt aus:
QteMUA::QteMUA( QWidget *parent, const char *name ) : QWidget( parent, name ) { // als Objekt definiert: // this ist parent (FALSE sagt lediglich, dass es readonly ist) QComboBox boxFolders(FALSE,this,"Folders");
Wenn du ein QWidget so definierst, wird es auf dem Stack abgelegt. Wenn der Code des Konstruktors nun abgelaufen ist, werden ja alle Objekte vom Stack gelöscht => die QComboBox gleich mit...
// so würde es angezeigt werden (wenn man unten dann // boxFolders.(methode) durch boxFolders->(methode) ersetzen // würde natürlich
//boxFolders = new QComboBox ( FALSE, this, "Folders" ); boxFolders.setGeometry(0,0,80,20); boxFolders.insertItem ( (QString) "Inbox", Inbox ); boxFolders.show();
So bleibt es aber dunkel.
Da nach Ablauf des Konstruktors ja kein Objekt mehr da ist => es wird keins Angezeigt. Normalerweise definiert man _alle_ sichtbaren (und innerhalb der Klasse benötigten) Widgets im Headerfile der Klasse im 'private' Abschnitt
class QteMUA : public QWidget { public: QteMUA(QWidget *parent = 0, const char *name = 0); ~QteMUA();
private: QComboBox *boxFolders; QButton *myButton; };
QteMUA::QteMUA(QWidget *parent, const char *name) : QWidget(parent, name) { boxFolders = new QComboBox(false, this, "Folders"); Q_CHECK_PTR(boxFolders); boxFolders->setGeometry(0, 0, 80, 20); boxFolders->insertItem(i18n("Inbox"), inbox); }
So liegen alle sichtbaren Objekte auf dem Heap und stehen wärend der ganzen RunTime des Programms zur Verfügung
Ciao, Tobias
Am Mittwoch, dem 05. Dezember 2001 um 20:13:43, schrieb Andre Schulze:
ich habe hier mal ne Frage an die Qt Experten: warum sind Widgets nicht sichtbar, die als Objekt definiert wurden, wohingegen mittels des new Operators erzeugte Widgets sichtbar sind? Ein meinWidget.show() habe ich nat?rlich auch gesagt - ohne Erfolg. Im Tutorial ist gleich im ersten Beispiel der Fall dabei, wo ein Widget so instanziiert wurde:
QPushButton hello( "Hello world!", 0 );
Der Blick in die Glaskugel sagt mir, dass du eigentlich ein
QPushButton hello( "Hello world!", this);
willst. Um mehr zu sagen, braeuchte man Beispielquellen.
Torsten
On Wed, Dec 05, 2001 at 08:13:43PM +0100, Andre Schulze wrote:
Moin,
ich habe hier mal ne Frage an die Qt Experten: warum sind Widgets nicht sichtbar, die als Objekt definiert wurden, wohingegen mittels des new Operators erzeugte Widgets sichtbar sind?
Widgets als Objekt zu definieren, ist keine sehr gute Idee, es geht vielleicht nocht mit einigen TOP-Level-Widgets. Denn am Ende rufen alle Widgets ein "delete this;" auf, und das geht bei Widgets, die nicht auf dem Heap liegen, daneben ...
Ein meinWidget.show() habe ich natürlich auch gesagt - ohne Erfolg. Im Tutorial ist gleich im ersten Beispiel der Fall dabei, wo ein Widget so instanziiert wurde:
QPushButton hello( "Hello world!", 0 );
Weil Du wahrscheinlich dann doch ein hello.show() dabei hast.
Du bist Dir sicher, daß das Eltern-Widget sichtbar geworden ist?
Heiko
On Thu, Dec 06, 2001 at 10:14:05AM +0100, Heiko Schlittermann wrote:
On Wed, Dec 05, 2001 at 08:13:43PM +0100, Andre Schulze wrote:
Moin,
ich habe hier mal ne Frage an die Qt Experten: warum sind Widgets nicht sichtbar, die als Objekt definiert wurden, wohingegen mittels des new Operators erzeugte Widgets sichtbar sind?
Widgets als Objekt zu definieren, ist keine sehr gute Idee, es geht vielleicht nocht mit einigen TOP-Level-Widgets. Denn am Ende rufen alle Widgets ein "delete this;" auf, und das geht bei Widgets, die nicht auf dem Heap liegen, daneben ...
Du kannst ein QWidget auch auf dem Stack erzeugen, es muss nur von dort verschwunden sein, bevor der Destruktor seines parentWidget() aufgerufen wird... Beispiel:
switch (pm.exec(QCursor::pos())) { case 1: { // wird erzeugt QDialog dlg(this, "colordlg", true); dlg.exec();
// wird zerstört } break; case 2: ...
Ciao, Tobias
lug-dd@mailman.schlittermann.de
-
Andre Schulze -
Eric Schaefer -
Heiko Schlittermann -
Josef Spillner -
Stephan Goetter -
Tobias Koenig -
Torsten Werner