Warum keine STL in GUI-Libs?
-
rüdiger schrieb:
Optimizer schrieb:
Weil die GUI-Libs dann als Sourcecode vorliegen müssen (zumindest wenn sie die Standard-Container nicht nur intern benutzen).
Ne, der Source Code muss nur für Template Code vorliegen und nicht für Code, der instanziierte Templates benutzt, da dies zur Compile-Zeit der Library geschieht.
Dann muß ich aber die selber STL-Implementierung verwenden wie die mit der die Library kompiliert wurde. Ich denke darauf wollte Optimizer hinaus. Und das stellt ein nicht zu verachtendes technisches Problem dar.
-
Genau. Die selbe Implementierung, die selbe Version dieser Implementierung und den selben Compiler. So viele Versionen einer Lib kann Microsoft natürlich anbieten, weil sie nur ihre eigenen Plattformen unterstützen.
Artchi schrieb:
Optimizer schrieb:
Für Opensource-Libs ist das natürlich sowieso kein Problem, aber für Sachen wie MFC wahrscheinlich schon.
Auch die MFC hat mittlerweile Templates im Einsatz. Wie oben bereits gesagt: der Grund hat keine technische Bewandnisse, sondern rein historische. Rüdiger hat es auch noch mal klargestellt.
Das ist AFAIK auch nicht von einen Compiler auf den nächsten übertragbar. Mit komischen Frickel-Tricks und precompiled headers kriegen sie es ein bisschen brauchbar hin aber richtig toll ist das leider nicht. Hier wäre die bessere Lösung IMHO wirklich, die relevanten Teile des Programms und der Lib erst zur Laufzeit zu compilieren. Verstehe ich eh nicht, dass nicht jedes Windows-System einen Compiler hat, den Programme über ein API standardmäßig nutzen können (abgesehen vom .Net Framework).
-
@Jester! Ja, aber in Reallife ist das nicht der Grund gewesen. Ich kann viele eventuelle Gründe für dies und jenes Aufführen, was aber nicht der ursprüngliche Grund war. Und Optimizers Grund ist nicht der ursprüngliche Grund, warum z.B. wxWidgets eine eigene Containersammlung mitbringt. Auch bei Qt ist das nicht der Fall. Selbst die neuen Qt4-Container sind aus einem Grund entwickelt worden: man mag die STL nicht. Punkt! Auch Ultimate++ hat seine eigene NTL entwickelt. Grund? Weil die STL denen nicht gefällt. Punkt! Kenne niemanden, der den Grund nennt, das es Versionskonflikte o.ä. gibt. Und historische Gründe überwiegen bei älteren Libs noch mehr, als die der Geschmacksgründe.
Da könnt ihr noch soviel hypothetische Beweggründe aufführen, es sind nicht DIE Reallife-Gründe.
-
Irgendwie habt ihr alle recht
Bei wxWidgets und QT ist es wohl so, das ursprünglich die STL damals noch nicht soweit war.
wxWidgets entschiedt sich, völlig auf Templates zu verzichten, um möglichst viele Plattformen sicher
abdecken zu können, QT entschied sich für modernes Design, mit Templates.
Und da Trolltech QT als Plattform wohl betrachtet, wollte man dann wohl auch seine eigenen
Container etc. haben, zu dem ja die std::strings nicht gerade das Gelbe vom Ei sind.phlox
-
Artchi schrieb:
Da könnt ihr noch soviel hypothetische Beweggründe aufführen, es sind nicht DIE Reallife-Gründe.
Aber wenn die Welt jetzt nicht schwarz-weiß wäre und es möglicherweise noch weitere Gründe außer DEM GRUND(tm) gäbe, dann würde das schon ein Grund sein oder? Insbesondere erklärt es auch, warum auch neuer libs das nicht machen und warum nicht schon viele libs auf STL umgestellt haben.
-
Dann wäre es schon ein Grund, Richtig! 
Im ernst: ich gehe erstmal davon aus, was die Projekte für Gründe nennen. Warum auch nicht? Man kann in den Dokus der jeweiligen GUI-Libs sehr schön nachlesen, warum sie die STL (oh man, es ist die Standardlib, nicht STL!) nicht benutzen. Sie benennen die Gründe sogar in mehr als ein oder zwei Sätzen. Ich bezweifel mal, das sie den Versionskonflikt verheimlichen würden, wenn es einer ihrer Gründe wäre. Danach richte ich meine Antwort in diesem Thread, wenn jemand nach den Gründen fragt. (on topic!)
-
Achja, schau mal warum Trolltech in Qt4 ein komplett neues Iterator-System designed und implementiert hat. Sie hätten bei der Umstellung ja die Std-Iteratoren nehmen können, oder? Diese finden sie aber doof (fehleranfällig) und haben Java-like Iteratoren eingebaut. D.h. das Design ist grundlägend anders. Selbst wenn es keine Versionskonflikte geben würde, würden sie diese in Qt4 nicht benutzen. Ihre alten Iteratoren waren Std-Iteratoren-like.
Die Ultimate++ ist auch eine neue GUI-Lib. Die haben die NTL entwickelt. Einfach, weil ihnen die Copy-Semantik von z.B. vector<typ> nicht gefallen hat. Pointer-Container wiederrum gefallen ihnen nicht, falls jemand auf vector<typ*> kommen sollte. Weil dann die autom. Verwaltung wegfällt (die wiederrum bei Copy-Semantik vorhanden wäre
Teufelskreis). Also, auch ohne Versionskonflikt wäre die NTL entstanden.wxWidgets wiederrum reitet elend lange darauf rum, das nicht jede Plattform eine komplette Std-Lib haben könnte
worst-cast-Scenario. Versionskonflikt kein Grund.
-
GUI + C++ suckt halt immer noch.
-
Das Problem ist eigentlich grundsätzlicher und nicht auf GUI-Libs beschränkt. Da war doch immer das Argument, dass man in C++ eben den Weg gewählt hat, möglichst wenig in den Standard zu packen und viel über externe Bibliotheken zu lösen. So wie es aussieht, wird auch der minimale Standard mangels gutem Design nicht angenommen und deshalb alles über externe Libs gelöst.
Aber das wissen wir alle schon lange und es ist in der professionellen Anwendungsentwicklung längst Realität, dass man sich ein komplette Framework aussucht und damit durchgehend arbeitet. Bei Java oder .Net arbeiten die Frameworks meistens mit dem standardmäßig vorhandenen zusammen (zum Beispiel arbeiten O/R-Mapper mit System.Data-Datenstrukturen), bei C++ besteht aus von Artchi genannten Gründen eher die Tendenz, komplett eigene Frameworks zu entwickeln. Ich fand es jetzt aber interessant das zu hinterfragen, warum das alles so ist und jetzt wissen wir es. *freu*
-
Jester schrieb:
rüdiger schrieb:
Optimizer schrieb:
Weil die GUI-Libs dann als Sourcecode vorliegen müssen (zumindest wenn sie die Standard-Container nicht nur intern benutzen).
Ne, der Source Code muss nur für Template Code vorliegen und nicht für Code, der instanziierte Templates benutzt, da dies zur Compile-Zeit der Library geschieht.
Dann muß ich aber die selber STL-Implementierung verwenden wie die mit der die Library kompiliert wurde. Ich denke darauf wollte Optimizer hinaus. Und das stellt ein nicht zu verachtendes technisches Problem dar.
Die C++-ABI umfasst ja auch solche Details. Daher muss man nur darauf achten, dass die Compiler die gleiche ABI haben, was man je eh machen sollte.
-
Es gibt doch sicher kein C++ ABI sondern höchstens etwas, das sich die Compiler-Hersteller selbst definieren. Intels Compiler und der g++ sollen ja eingeschränkt kompatible Binaries erzeugen, aber ein ultimatives C++ ABI wird wohl ein Traum bleiben. Hier haben Systeme mit JIT-compilierung klare Vorteile, da das "Binary" hier ein klar definierter Zwischencode ist.
-
Ja, Optimizer. Jetzt haste wieder ein Happerlie gefunden, um wieder gegen C++ zu stänkern. Immer wieder schön, wenn die "Sprache X"-Fraktion einen "Sprache X vs C++"-Thread startet.
Hab schon den wöchentlichen Flamewar der Anti-C++-Fans vermisst. 
-
Optimizer schrieb:
Es gibt doch sicher kein C++ ABI sondern höchstens etwas, das sich die Compiler-Hersteller selbst definieren. Intels Compiler und der g++ sollen ja eingeschränkt kompatible Binaries erzeugen, aber ein ultimatives C++ ABI wird wohl ein Traum bleiben. Hier haben Systeme mit JIT-compilierung klare Vorteile, da das "Binary" hier ein klar definierter Zwischencode ist.
Nö, eine einheitliche gibt es nicht. Aber bei der System-Definition legt man eben eine ABI vor. Das ist also mehr oder weniger Systemabhängig. Dafür muss man eh neu kompilieren.
JIT hat hier keinen Vorteil. Was du meinst ist wohl, dass die Java Spezifikation auch eine Spezifikation für den Zwischencode enthält.
-
Artchi schrieb:
Ja, Optimizer. Jetzt haste wieder ein Happerlie gefunden, um wieder gegen C++ zu stänkern. Immer wieder schön, wenn die "Sprache X"-Fraktion einen "Sprache X vs C++"-Thread startet.
Hab schon den wöchentlichen Flamewar der Anti-C++-Fans vermisst. Wieso, gibt doch auch JIT-compiliertes C++. Da ist auch noch zufälligerweise ne gute Standard-Bibliothek dabei.
-
rüdiger schrieb:
Was du meinst ist wohl, dass die Java Spezifikation auch eine Spezifikation für den Zwischencode enthält.
Ja, stimmt. Und dass ich halt dann trotzdem beliebigen native Code erstellen kann, ohne inkompatibel zu werden mit anderen Zwischencode-Binaries. Das ist natürlich nichts, was man für Standard-C++ nicht auch erreichen könnte. Praktisch jeder Compiler erzeugt nicht sofort native code aus dem Parsebaum, sondern erstmal Zwischencode. Den müsste man nur normen.
-
Optimizer schrieb:
Den müsste man nur normen.
*lol* "nur". Ich will nicht noch 4 Jahre länger auf den neuen Standard warten
Aber obs wirklich so einfach ist, keine Ahnung, aber dumm sind die Menschen im Komitee nun weisgott auch nicht. Haben evtl Gründe, warum es den bei C++ nicht gibt (reine Spekulation jetzt von mir, bevor hier wieder einige nach Quellen schreien)Zwischenruf: SmartWin++ nutz aber STL soweit ich weis(und auch boost). Sehr interessante Bibliothek!
-
Pellaeon schrieb:
Optimizer schrieb:
Den müsste man nur normen.
*lol* "nur". Ich will nicht noch 4 Jahre länger auf den neuen Standard warten
Aber obs wirklich so einfach ist, keine Ahnung, aber dumm sind die Menschen im Komitee nun weisgott auch nicht. Haben evtl Gründe, warum es den bei C++ nicht gibt (reine Spekulation jetzt von mir, bevor hier wieder einige nach Quellen schreien)Na ja, in Arbeit ist sowas ja, nur wirds aus Zeitgruenden nicht in 0x aufgenommen:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1496.html
-
Hab ihn nur übeflogen, aber hoch interessanter Vorschlag.
-
Ja, in dem man das über dynamische Libs löst, wäre das ein Lösungsweg. Funktioniert ja unter Windows mit DLLs und COM ja praktisch schon, sogar über Sprachgrenzen hinweg. Nur es geht hier glaube ich um Templates und das GUI-Libs nicht ohne Source ausgeleifert werden können. Wird man das dadurch lösen können?
cpp-std.dll * std::string * std::vector<T>Wie soll das gehen? Templates haben nunmal die Angewohnheit zur Compilezeit gebaut werden zu können. Aber ich kann mir sowas vorstellen:
cpp-gui.dll (Link to cpp-std.dll) * gui::component * gui::container : public std::vector<gui::component>Naja, das Problem verstehe ich aber heute schon nicht wirklich. Wenn ich mingw benutze, habe ich wahrscheinlich den STLport drauf. Muß mir der GUI-Lib-Provider halt dafür ein fertiges Binary liefern, will er den Source nicht rausrücken. (Darauf will Optimizer hinaus?) Habe ich MSVC7.1 muß er mir dafür ein fertiges Binary liefern. Eigentlich kein Problem.
Aber ehrlich? Die meisten liefern Sourcecode aus. Selbst die MFC liegt im Sourcecode vor und man darf sie an eigene Bedürfnisse anpassen. (dann übernimmt aber MS verständlicherweise keinen Support mehr dafür)
Das mit den dynamischen Libs ist auf jeden Fall ein Thema, das das Komitee angehen muß und auch nach 2009 tun wird. Siehe auch http://herbsutter.spaces.live.com/blog/cns!2D4327CC297151BB!159.entry
Auch das Build-System wird sich das Komitee bekanntlich angehen. Dann werden wir endlich das Header-Konzept los. Das finde ich wichtiger, von der Prio.
-
Naja, das Problem verstehe ich aber heute schon nicht wirklich. Wenn ich mingw benutze, habe ich wahrscheinlich den STLport drauf. Muß mir der GUI-Lib-Provider halt dafür ein fertiges Binary liefern, will er den Source nicht rausrücken. (Darauf will Optimizer hinaus?) Habe ich MSVC7.1 muß er mir dafür ein fertiges Binary liefern. Eigentlich kein Problem.
Entschuldigung, aber das kann irgendwo auch nicht dein Ernst sein. Es kann nicht sein, dass ich nicht eine DLL schreiben kann, wo eine Klasse List<T> drin ist (ohne eingesetzten Typparameter), die dann jeder standardkonforme Compiler mir ermöglicht zu nutzen, aber für nicht-Template Klassen schon.
Oder das selbst, wenn nur eine List<int> drin ist, dass die DLL dann genau für einen spezifischen Compiler nur geht. Rüdiger hat zu Recht angemerkt, dass man dafür vielleicht auch kein neumodisches JIT-compiling braucht, man könnte zum Beispiel die DLL als standardisierten Zwischencode anbieten. Aber wenn sowas wieder gar nicht gehen soll, wenn so etwas für Templates einfach gar nicht möglich ist, dann kann ich nur noch zu dem Schluss kommen, dass Templates in die moderne Welt nicht mehr reinpassen. Dynamisches Linken passt jedenfalls gut in die heutige Zeit, also da muss das Kommitee jetzt wirklich was gescheites hindrehen.