Warum schreibt jeder Compiler hersteller seine eigene Standardlibrary?

Wieso gibts für den Plattformunabhängigen Teil (also z.B. std::vector, std::list, std::sort...) nicht einen Opensourcecode den jeder Compilerhersteller nimmt? Wieso schreibt da jeder seine eigene Version?

Weil jeder meint es besser zu können

otze

weil jeder compiler andere nicht standard erweiterungen hat, die dann einen geschwindigkeitsboost geben können. Das ist gut in den Benchmarks und darum direkt gut für den eigenen Geldbeutel.

Außerdem gibt es eine Standardbibliothek die von vielen benutzt wird, nämlich die von Dinkumware.

Warum schreibt jemand Linux, wo wir doch Windows haben? Warum Benz sein eigenes Auto gebaut, wo doch schon Henry Ford ein Auto gebaut hat? Warum gibts Pepsi, wo es doch schon die Coca Cola gab?

Naja... der Mensch strebt danach, es besser zu machen, als jemand anderes.

sothis_

nur wird meistens die schlechtere alternative benutzt

Kann man an nem std::vector noch soviel verbessern?

BarnieGeroellheimer schrieb:

Warum schreibt jemand Linux, wo wir doch Windows haben? Warum Benz sein eigenes Auto gebaut, wo doch schon Henry Ford ein Auto gebaut hat? Warum gibts Pepsi, wo es doch schon die Coca Cola gab?

Einer der dümmsten Vergleiche seit langem. Der Standard schreibt vor, was die Libs können müssen und wie sie aussehen müssen, da gibt es kaum Spielraum was anders zu machen. Bei deinen Beispielen gibt es keinen Standard der sagt wie ein OS, Auto oder Getränk aussehen muss.

Berufspenner

dummmmmmmm schrieb:

BarnieGeroellheimer schrieb:

Warum schreibt jemand Linux, wo wir doch Windows haben? Warum Benz sein eigenes Auto gebaut, wo doch schon Henry Ford ein Auto gebaut hat? Warum gibts Pepsi, wo es doch schon die Coca Cola gab?

Einer der dümmsten Vergleiche seit langem. Der Standard schreibt vor, was die Libs können müssen und wie sie aussehen müssen, da gibt es kaum Spielraum was anders zu machen. Bei deinen Beispielen gibt es keinen Standard der sagt wie ein OS, Auto oder Getränk aussehen muss.

Mal abgesehen davon, dass der, der etwas als erstes gemacht hat, es ja nicht gleich perfekt gemacht haben muss. Es besteht immer Spielraum für Verbesserungen. Ein Standard hebt sich davon aber komplett ab. Da brodelt nicht jeder seine eigene Suppe sondern alle verfolgen ein Rezept.

Dravere

dummmmmmmm schrieb:

BarnieGeroellheimer schrieb:

Warum schreibt jemand Linux, wo wir doch Windows haben? Warum Benz sein eigenes Auto gebaut, wo doch schon Henry Ford ein Auto gebaut hat? Warum gibts Pepsi, wo es doch schon die Coca Cola gab?

Einer der dümmsten Vergleiche seit langem. Der Standard schreibt vor, was die Libs können müssen und wie sie aussehen müssen, da gibt es kaum Spielraum was anders zu machen. Bei deinen Beispielen gibt es keinen Standard der sagt wie ein OS, Auto oder Getränk aussehen muss.

Kein Spielraum? Guter Witz!
Es gibt zwar Vorschriften, wie die Schnittstelle auszusehen hat und wie es zu funktionieren hat. Aber mir wäre neu, dass es irgendwo Vorschriften über die genaue Implementation gibt. Das kann jeder machen wie er möchte. Und wenn du schon mal mit ein paar Leuten eine gleiche Aufgabe gelöst hast, dann wirst du hoffentlich bemerkt haben, wie man die gleiche Aufgabe auf zig unterschiedliche Wege lösen kann. Deshalb gibt es teilweise auch starke Unterschiede zwischen den Bibliotheken, was Geschwindigkeit und/oder Grösse angeht.

Grüssli

Dravere schrieb:

dummmmmmmm schrieb:

BarnieGeroellheimer schrieb:

Warum schreibt jemand Linux, wo wir doch Windows haben? Warum Benz sein eigenes Auto gebaut, wo doch schon Henry Ford ein Auto gebaut hat? Warum gibts Pepsi, wo es doch schon die Coca Cola gab?

Einer der dümmsten Vergleiche seit langem. Der Standard schreibt vor, was die Libs können müssen und wie sie aussehen müssen, da gibt es kaum Spielraum was anders zu machen. Bei deinen Beispielen gibt es keinen Standard der sagt wie ein OS, Auto oder Getränk aussehen muss.

Kein Spielraum? Guter Witz!
Es gibt zwar Vorschriften, wie die Schnittstelle auszusehen hat und wie es zu funktionieren hat. Aber mir wäre neu, dass es irgendwo Vorschriften über die genaue Implementation gibt. Das kann jeder machen wie er möchte. Und wenn du schon mal mit ein paar Leuten eine gleiche Aufgabe gelöst hast, dann wirst du hoffentlich bemerkt haben, wie man die gleiche Aufgabe auf zig unterschiedliche Wege lösen kann. Deshalb gibt es teilweise auch starke Unterschiede zwischen den Bibliotheken, was Geschwindigkeit und/oder Grösse angeht.

Bist du zu dumm zum lesen oder schreibst du absichtlich was falsches? Ich hab nicht gesagt kein Spielraum, sondern kaum Spielraum. Und der Vergleich ist einfach deswegen dumm, weil es bei einem Getränk viel mehr Spielraum für Änderungen und Neuentwicklungen gibt als bei der StdLib.

Und außerdem hätte es auch Vorteile, wenn man einen gemeinsamen Code verwendet. Dann müsste man nicht immer die verschiedenen Dokus der Compilerherstellers lesen und schauen ob es irgendwo eine kleine Änderung gibt, die man beachten muss.

Shade Of Mine

dummmmmmmm schrieb:

Bist du zu dumm zum lesen oder schreibst du absichtlich was falsches? Ich hab nicht gesagt kein Spielraum, sondern kaum Spielraum.

Auch wenn du noch mehr schimpfst, du liegst trotzdem falsch.

Der Spielraum ist relativ gross. Es gibt zB massig optimierungs moeglichkeiten bei den algos und den datenstrukturen. dann gibt es natuerlich eine menge debug moeglichkeiten. das alles ohne den standard zu verletzen.

aber dann gibt es massig erweiterungen: hash maps, single linked lists, skip lists,...

und natuerlich kann jede standard library dann die vorteile des jeweiligen compilers nutzen bzw. um die bugs herumschiffen.

Shade Of Mine schrieb:

dummmmmmmm schrieb:

Bist du zu dumm zum lesen oder schreibst du absichtlich was falsches? Ich hab nicht gesagt kein Spielraum, sondern kaum Spielraum.

Auch wenn du noch mehr schimpfst, du liegst trotzdem falsch.

Ich hab mich aufgeregt, dass einem hier andere Wörter in den Mund gelegt werden.

Der Spielraum ist relativ gross.

Relativ gross ist relativ und im Vergleich zu nem OS oder Getränk ist der Spielraum relativ klein, sogar sehr klein. Der Vergleich war einfach total falsch.

tntnet

dummmmmmmm schrieb:

Und außerdem hätte es auch Vorteile, wenn man einen gemeinsamen Code verwendet. Dann müsste man nicht immer die verschiedenen Dokus der Compilerherstellers lesen und schauen ob es irgendwo eine kleine Änderung gibt, die man beachten muss.

Genau das braucht man mit einer Standardlibrary bzw. einem ANSI-Standard nicht. Wenn irgendetwas unklar ist, lese ich im Zweifelsfall im C++-Standard nach. Ansonsten kann ich die Doku jeder beliebigen Implementierung lesen und kann sie auf andere übertragen. Funktioniert etwas nicht, wie im Standard vorgeschrieben, dann ist das ein Bug in der Implementierung und ich muss mir überlegen, wie ich damit um gehe.

Der Grund, warum es mehrere Implementierungen gibt ist nicht einfach das nih Syndrom (not invented here), wie es hier so negativ dargestellt wird. Das Standardkomitee hat festgelegt, was die Bibliothek können soll und die Compilerhersteller haben sich daran gemacht, eine Implementierung zu machen. Und es ist gut, dass wir keine Monokultur haben.

Die Vorgehensweise ist etwa mit anderen Standards vergleichbar. Wir nehmen einfach mal eine Schraube. Die ist standardisiert und dennoch gibt es mehrere Hersteller. Oder ein Autoreifen. Die Größen sind festgelegt, aber dennoch gibt es hier einen Wettbewerb, wer den besten Reifen hat.

tntnet schrieb:

dummmmmmmm schrieb:

Und außerdem hätte es auch Vorteile, wenn man einen gemeinsamen Code verwendet. Dann müsste man nicht immer die verschiedenen Dokus der Compilerherstellers lesen und schauen ob es irgendwo eine kleine Änderung gibt, die man beachten muss.

Genau das braucht man mit einer Standardlibrary bzw. einem ANSI-Standard nicht. Wenn irgendetwas unklar ist, lese ich im Zweifelsfall im C++-Standard nach. Ansonsten kann ich die Doku jeder beliebigen Implementierung lesen und kann sie auf andere übertragen.

Nicht immer. http://www.c-plusplus.net/forum/viewtopic-var-p-is-1556610.html#1556610 da musst du ganz genau die Doku dieses Herstellers bis zum letzten Operator lesen, obwohl du eigentlich weißt wie der Operator funktioniert.

hustbaer

detroit schrieb:

tntnet schrieb:

dummmmmmmm schrieb:

Und außerdem hätte es auch Vorteile, wenn man einen gemeinsamen Code verwendet. Dann müsste man nicht immer die verschiedenen Dokus der Compilerherstellers lesen und schauen ob es irgendwo eine kleine Änderung gibt, die man beachten muss.

Genau das braucht man mit einer Standardlibrary bzw. einem ANSI-Standard nicht. Wenn irgendetwas unklar ist, lese ich im Zweifelsfall im C++-Standard nach. Ansonsten kann ich die Doku jeder beliebigen Implementierung lesen und kann sie auf andere übertragen.

Nicht immer. http://www.c-plusplus.net/forum/viewtopic-var-p-is-1556610.html#1556610 da musst du ganz genau die Doku dieses Herstellers bis zum letzten Operator lesen, obwohl du eigentlich weißt wie der Operator funktioniert.

Wieso, was "muss" man denn da wissen? Der operator [] entspricht dem dokumentierten Verhalten, und aus.

Das er langsamer ist. Das er immer rangechecks macht, außer man setzt ein define. "Ansonsten kann ich die Doku jeder beliebigen Implementierung lesen und kann sie auf andere übertragen" geht da nicht, weil in anderen nix von dem define steht.

hustbaer

Er ist O(1) und das ist alles was der Standard vorschreibt.
Und dass er Range-Checks macht ist ein einem fehlerfreien Programm auch egal.

Die Range-Checks sind ein Implementierungs-Detail, welches halt dokumentiert ist. Du musst das nicht wissen um mit der Standard-Library vom MSVC arbeiten zu können, und dein Programm wird auch genauso mit der Standard-Library des GCC funktionieren wenn du es auf MSVC entwickelt hast, solange du dich an den Standard gehalten hast.

Code auf lineare Laufzeit zu optimieren ist ein gänzlich eigenes Thema. Hier spielt nicht nur die Implementierung der Standard-Library mit rein, sondern der Compiler, die CPU, das OS, ... viel zu viel einfach. Sprich: es würde diesbezüglich nicht ausreichen eine einzige Implementierung der Standard-Library zu haben.

Also nochmal: wieso glaubst du wissen zu müssen was da in den Untiefen der Implementierung vorsich geht wenn du operator [] aufrufst?

hustbaer schrieb:

Code auf lineare Laufzeit zu optimieren ist ein gänzlich eigenes Thema.

Du meinst wohl den Algorithmus, aber egal.

Die Aussage war "Ansonsten kann ich die Doku jeder beliebigen Implementierung lesen und kann sie auf andere übertragen" und das stimmt halt nun mal im Detail nicht und daran ändern auch deine Argumente die mehr oder weniger am Thema vorbeigehen nichts.

ghorst

ich glaube du verwechselst gerade etwas. der standard definiert ausschließlich das interface (die komplexitätsbeschreibung sind bekanntlich ungleich dem laufzeitverhalten, sondern geben eben nur einen sehr groben rahmen vor). das ist nebenbei usus. bei der libc, posix, java-lib, opengl, u.ä. sieht es genauso aus. da kannst du auch auf höchst unterschiedliches laufzeitverhalten treffen (und auch höchst unterschiedliche implementierungen...).

beim programmieren solltest du dich aber vom interface leiten lassen und nicht von der konkreten implementierung, die kann sich sehr spontan und grundlegend ändern. (ok, eine ausnahme gibt es: wenn man weiß, dass lib-x.y.z eine total verhunste implementierung hat, könnte man da mit einem "#ifdef" eine sondercode einführen. mehr aber bitte nicht. soetwas kommt bei den aktuellen c++-libs aber eigentlich nicht mehr vor. mir ist zumindest nichts bekannt, wo es so grausam ist, dass man das generell machen muss.)
wenn man dann hinterher der meinung ist, dass der code zu langsam ist, sollte man erst schauen, woran das wirklich liegt (profiler). dass es an den range-checks wirklich liegt, ist meistens auszuschließen. die kosten quasi keine laufzeit.

btw. ich finde die ms-variante ein bisschen unglücklich, da sie leider dazu verleitet nicht mehr standardkonform zu programmieren, sondern sich darauf zu verlassen, dass da was geworfen wird. das dumme an der sache ist vor allem, dass der code beim portieren nicht unbedingt krachen geht, aber eben dann auch mal mist macht.