-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Saturday 20 April 2002 00:07, Torsten Werner wrote:
Am Freitag, dem 19. April 2002 um 22:07:39, schrieb Konrad Rosenbaum:
obj1.connect(button,SIGNAL(click()),SLOT(calcsomething())); obj2.connect(button,SIGNAL(click()),SLOT(showsomething()));
button.onClick = bind(ersteFunktion, bind(zweiteFunktion, _1));
beispielsweise oder auch beliebig kompliziertere Konstrukte
Da sagst du schon einen meiner Kritikpunkte: "kompliziert".
Was mache ich eigenlich, wenn sich die Assoziationen mittendrin veraendern. Z.B. ein Update-Button, an dem etwa zwei dutzend Elemente haengen, die sich dynamisch veraendern koennen (es kommen staendig einzelne Elemente dazu oder gehen weg, abhaengig von den Daten, die anfallen).
Typsicherheit halte ich bei Qt auch nicht gerade fuer ein Problem:
Ähem, ich kann problemlos einen slot(int a) mit einem signal(double b) verbinden und merke das nicht beim Übersetzen. Bei mir dagegen kann ich sogar so etwas machen:
object.onChange = bind(&Label::setText, &myLabel, bind<string, int>(lexical_cast, _1));
object.onChange() hat ein int-Argument und kann trotzdem den Text eines Labels ändern, obwohl diese Funktion einen std::string erwartet. Eingebaute Typkonvertierungen wie int->double bzw. solche mit existierenden Konstruktor/Konvertierer wie const char*->std::string gibt es bei mir natürlich "for free".
hmm, was fuer ein Ausdruck ist jetzt "bind<string, int>(lexical_cast, _1)"? Cast? Template? Wenn Template, dann lies Dir mal bitte durch, warum Qt keine Templates verwendet (doc/html/templates.html).
Ich nehme an, wenn ich <...> wegliese bekaeme ich einen Type-Mismatch - oder?
Was, wenn ich einen neuen Typ einfuehre, den bind noch nicht kennt? Muss ich dann bind ueberschreiben?
Was mache ich mit Konstrukten, wie diesem:
connect(SIGNAL(abc(int,int,QString,float)),obj1,SLOT(int,int)))
- ->bei Qt vollkommen legaler und funktionierender Code. Was muss ich bei Deiner Bibliothek machen, damit das funktioniert?
- muessen alle Objekte von QObject abgeleitet sein, damit die
Qt-Mechanismen funktionieren, ist diese Bedingung erfuellt funktioniert alles ohne Probleme. Ist sie nicht erfuellt beschwert sich der Compiler.
Genau damit ist keine saubere Trennung von Anwendungs- und GUI-Code möglich. Bei meinem Wrapper geht das selbstverständlich: reiner Anwendungcode braucht nicht den bollin.h-Header einzuziehen und
Wieso kommst Du auf sowas? Etwa ein Viertel der Qt-Klassen haben nichts, aber auch gar nichts, mit GUI zu tun, Beispiele:
QObject, QString, QDate, QDir, etc.pp.
Ich habe z.B. auch schon Qt-basierte Applikationen gebaut, ohne irgendetwas darzustellen (einen Daemon, um genau zu sein).
natürlich wird auch kein moc benötigt.
Hmm, wieso ist das ein Vorteil. So viel Zeit verbraet der doch gar nicht (im Vergleich zum eigentlichen Compiler).
Wer ein Programm nicht so weit testet, dass jede Code-Stelle mindestens einmal angefahren wurde, sollte sich ueberlegen warum er so viele Bug-Reports bekommt...
Damit findest du trotzdem nicht alle Fehler.
Weiss ich. Aber das ist schonmal ein wichtiger Teil dessen, was man allgemein "Unittest" nennt. Aber zumindest habe ich bei Qt dann bewiesen, dass alle echten Typfehler weg sind und dass der Code zumindest einigermassen korrekt laeuft, wenn man macht, was man soll. Was noch fehlt sind: Funktionstests, Integration-Tests, usw. und schliesslich Exception-Tests (fuer die werden, nach meiner Erfahrung, Tester am meisten gehasst und die dauern am laengsten).
Konrad
- -- BOFH excuse #134:
because of network lag due to too many people playing deathmatch