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).

Warum? Gilt das etwa auch für Libs die nur für Windows verfügbar sind?

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.

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.

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.

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.

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).

Da könnt ihr noch soviel hypothetische Beweggründe aufführen, es sind nicht DIE Reallife-Gründe.

phlox

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.

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!)

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.

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*

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.

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.

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.

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.

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!

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