Am Samstag, dem 20. April 2002 um 16:48:35, schrieb Konrad Rosenbaum:
"Der Vulkan bricht halt aus, ob jemand wegrennt ist ihm egal." ;-)
Das ist natürlich ein Argument, gegen das schwer anzukämpfen ist. Ich bin halt der Meinung, dass es prinzipiell möglich sein muss, den Vulkan zu stoppen oder was auch immer man noch Vulkanen antun kann.
Lt. Qt-Docu etwa 10-facher Aufwand eines einfachen Funktionsaufrufes. Da Ereignisse relativ selten sind (verglichen mit Warteschleifen und mathematischem Code) kann ich damit leben.
Ich möchte aber den Mechanismus aber auch für mathematischen Code einsetzen und dann soll er schnell sein.
Aber Kopien koennten ein Problem werden.
"Konjunktive sollten prinzipiell immer vermeidbar sein."
Templates haben noch einen weiteren Nachteil: jede Object-Datei erzeugt eine neue Instanz des Codes. Nur wenige Linker (der von GNU z.B. nicht) koennen soetwas wieder reduzieren.
Der GNU-Linker kann das seit dem ELF-Binärformat. Für andere Plattformen implementierte schon der egcs den -frepo workaround.
[Template vs. Funktion:]
Ich war davon ausgegangen, dass es eine einfache Funktion ist.
bind ist ein Funktionstemplate. ;-)
connect(SIGNAL(abc(int,int,QString,float)),obj1,SLOT(int,int)))
Ups, das sollte SLOT(def(int,int)) heissen.
- ->bei Qt vollkommen legaler und funktionierender Code.
Das ist kein legaler C++-Code, wenn die letzten beiden Argumente von abc keine Defaultwerte haben. Qt ist broken, wenn es das trotzdem tut. Wenn es aber Defaultwerte gibt, ist es legal und geht auch mit den von mir vorgestellten Konstrukten.
Ups, meine Bemerkung mit den Defaultargumenten passt hier gar nicht.
Wieso? Einem Signal gibst Du Parameter mit, die der Slot aufnehmen kann oder auch nicht. Wenn ein Slot nicht an Paramer 3 und 4 interessiert ist, dann brauch er den doch nicht abfangen muessen, nur weil irgendein dummes Signal den Parameter liefern koennte.
Das ist aber extrem fehleranfällig. Stell dir vor ich entferne die Parameter, weil ich der Meinung bin, ich bräuchte sie gar nicht. Normalerweise würde mich der Compiler dafür ohrfeigen, aber bei Qt kann ich nur hoffen, dass die Dummheit zur Laufzeit auffällt. Wenn es in 99 % der Fälle glatt läuft, habe ich ein Problem, den Fehler zu finden. Ergo, mir gefällt die statische Typprüfung in C++.
Was bitte hat ein Application Binary Interface mit einem Preprocessor zu tun?
Eine Klasse mit Q_OBJECT sieht in Wirklichkeit ganz anders aus, als es der Quelltext vermuten lässt -> ganz anderes Binary Interface. Das führt eventuell auch bei anderen Sachen zu Problemen, Stichwort: persistente Objekte.
Willst Du jetzt auch Embedded SQL verbieten?
Ich weiss gar nicht, was das ist. Wenn es elegantere und standardkonformere Lösungen als Embedded SQL gibt, würde ich es aber vermutlich auch nicht sehr mögen.
bind(lexical_cast, _1);
Hmm. Muss ich mir bei Gelegenheit mal ansehen, im Moment verstehe ich diesen Code nicht. :-(
Was mir an boost besonders gefällt, ist die Tatsache, das sie einem peer review unterliegt und das Mitglieder des C++-Standardisierungsgremiums dazu gehören. Das lässt auf langfristige Ausrichtung und Portabilität hoffen.
- Java ist ebenso eine stark typgebundene Sprache wie C++.
Aber Java kennt genausowenig wie C++ ohne Bibliothekunterstützung Multidispatch. In C++ kann man aber die Unterstützung komplett in Bibliotheken kapseln.
- AFAIK wurde double dispatch von SmallTalk _erfunden_!
Meine Quellen erwähnen das gar nicht, vielmehr erscheint es mir so, als käme das vom CLOS. Da ich SmallTalk aber nicht kenne, will ich mich lieber nicht streiten.
Ich versuche nur potentielle Schwachstellen aufzuzeigen, sag' Bescheid, wenn ich aufhoeren soll, dann schreib ich lieber Code als eMails.
So habe ich es auch nicht gemeint. Die Diskussion geht mir etwas am Thema meiner Bibliothek vorbei, aber ich finde sie trotzdem nützlich.
Torsten