Warum keine STL in GUI-Libs?
-
Warum verwenden die ganzen Libs für GUIs (MFC, VLC, Qt, wx usw.) eigentlich nicht die STL? Ich fände das viel sauberer, man muss doch nicht immer das Rad neu erfinden.
-
Ich glaube dafür ist sie einfach zu spät in den Standard aufgenommen worden.
-
Die von dir genannten GUI-Libs sind schon alle stein alt, von vor 1998. Da gab es keinen ISO-C++-Standard (die STL schon, aber die interessiert hier nicht die Bohne, wenn wir von ISO-C++ reden).
Andere neuere Libs, wie gtkmm arbeiten dagegen mit der Standardlib zusammen. Andere, wie Ultimate++, mögen die Standardlib nicht. Die machen das sogar absichtlich.
Aber am Ende sollte man sich sowieso fragen, was eine Container-Klasen in einer GUI-Lib zusuchen haben?
Die Frage sollte eher lauten "Warum benutzen GUI-Libs nicht die Standardcontainer?".
-
Weil die GUI-Libs dann als Sourcecode vorliegen müssen (zumindest wenn sie die Standard-Container nicht nur intern benutzen).
-
Optimizer schrieb:
Weil die GUI-Libs dann als Sourcecode vorliegen müssen (zumindest wenn sie die Standard-Container nicht nur intern benutzen).
Warum? Gilt das etwa auch für Libs die nur für Windows verfügbar sind?
-
Die Standard-Container sind Templates. Damit du zum Beispiel als Parameter an eine Lib-Funktion so etwas übergeben kannst, muss der komplette Programmteil dem Compiler als Sourcecode vorliegen, damit er das Template instanzieren und diese Instanz compilieren kann. Ein Compiler A könnte mit dem Compilat von Compiler B nichts anfangen und mir ist auch kein template-fähiges Objektmodell bekannt, das vielleicht portabel wäre.
Wenn man natürlich definieren würde, wie so eine std::liststd::string in Binärform aussehen muss, dann geht das schon. Aber die Implementierungen unterscheiden sich je nach Compiler ganz erheblich.
Für Opensource-Libs ist das natürlich sowieso kein Problem, aber für Sachen wie MFC wahrscheinlich schon.
-
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.
-
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.
-
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.