Warum schreibt jeder Compiler hersteller seine eigene Standardlibrary?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
dummmmmmmm schrieb:
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.
Einfaches Beispiel: Bei std::set kann ich zur implementierung einen Rot-Schwarz-Baum oder einen AVL-Baum nehmen. Außerdem kann man compilerspezifische Sachen ausnutzen.
Nimm die funktion sin. Ein compiler hersteller kann diese ja auch mit hilfe von SSE berechnen lassen. Was schneller geht. Aber das gibt es ja nicht überall.
Der Gesetzgeber schreibt ja auch vor, dass jedes Auto, das zugelassen werden soll, einen Blinker hat, aber ich kann mir die Glühbirne darin aussuchen.
-
recyclecoder schrieb:
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?
ProgChild schrieb:
dummmmmmmm schrieb:
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.
Einfaches Beispiel: Bei std::set kann ich zur implementierung einen Rot-Schwarz-Baum oder einen AVL-Baum nehmen. Außerdem kann man compilerspezifische Sachen ausnutzen.
Nimm die funktion sin. Ein compiler hersteller kann diese ja auch mit hilfe von SSE berechnen lassen. Was schneller geht. Aber das gibt es ja nicht überall.
Der Gesetzgeber schreibt ja auch vor, dass jedes Auto, das zugelassen werden soll, einen Blinker hat, aber ich kann mir die Glühbirne darin aussuchen.
Und was für Gesetze gibts für Betriebssysteme?
-
Warum sollte es keinen Fortschritt mehr geben, wenn etwas Opensource ist?
-
BarnieGeroellheimer schrieb:
Warum Benz sein eigenes Auto gebaut, wo doch schon Henry Ford ein Auto gebaut hat?
Benz war ja wohl lange vor Ford da!
-
detroit schrieb:
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.
Nein ich meine nicht den Algorithmus, der "Algorithmus" bei operator [] bleibt der gleicht mit oder ohne Checks.
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.
Hihi. Du hast in einem Punkt Recht, aber das ist nicht der Punkt auf dem du rumreitest. Lustig eigentlich. Der Punkt in dem du Recht hast: die Doku von MSVC lässt sich nicht auf andere Implementierungen übertragen weil in der MSVC Doku die Checked-Iterator beschrieben sind, die es in anderen Implementierungen nicht geben muss. Von daher hätte man ein Problem wenn man die MSVC Doku liest, und dann davon ausgeht dass es überall die (non-standard) Checked-Iterators gibt.
Der Punkt auf dem du rumreitest ist allerdings wurscht, da die Checked-Iterator nichts sind wovon man wissen müsste wenn man ein Standard konformes Programm schreiben will. Ich kann also durchaus mit der C++ Standard als Grundlage arbeiten wenn ich mit MSVC und dessen Standardlibrary arbeite, weil die Checked-Iterators keinen Unterschied machen. Wenn du jetzt wieder sagst "ja aber die sind doch langsamer": langsamer als was? Der Zugriff ist O(1), und das ist alles was der Standard vorschreibt. Ob O(1) jetzt 1 nanosekunde ist oder 10 Sekunden ist egal.
Genau das meinte ich mit "auf lineare Laufzeit (zu) optimieren", und das hat nunmal mit dem Algorithmus oft garnix zu tun.
-
hustbaer schrieb:
Hihi. Du hast in einem Punkt Recht, aber das ist nicht der Punkt auf dem du rumreitest.
Eigentlich schon. Und man kann eine Doku auch beim Optimieren lesen nicht nur beim Programmieren und dann kann so ein unterschied schon was aus machen.
hustbaer schrieb:
Der Zugriff ist O(1), und das ist alles was der Standard vorschreibt. Ob O(1) jetzt 1 nanosekunde ist oder 10 Sekunden ist egal.
Genau das meinte ich mit "auf lineare Laufzeit (zu) optimieren", und das hat nunmal mit dem Algorithmus oft garnix zu tun.
Na, eben schon. Die Laufzeitkomplexität die du mit der O-Notation angibst ist die Laufzeitkomplexität des Algorithmus. Der Algorithmus bei [] ist im Prinzip eine Addition/Berechnung (und vlt. noch Checks) die unabhängig von der Größe ist, also O(1). Bei std::set, std::list oder ähnlichem verwendest du zum Zugirff einen Algorithmus der eine Laufzeitkomplexität von O(log(n)) oder O(n) hat. Um z.B. von linearer auf logarithmische Laufzeit zu kommen musst du den Algorithmus ändern und nicht nur ein paar Befehle im Code durch schnellere ersetzen oder checks, die O(1) haben, weg lassen.
