Warum schreibt jeder Compiler hersteller seine eigene Standardlibrary?
-
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.
-
Ach, kann es sein, dass du linear = O(n) mit konstant = O(1) verwechselst?
-
Sind die Leute die hier die Implementierung der Standardlibrary mit der Entwicklung eines Betriebssystems vergleichen dieselben, die ein noch-nie-dagewesenes-MMORPG(TM) programmieren? Sollte für die ja vergleichbar zum Programmieren eines Tetris Clones sein.
-
Man könnte wenigstens mal den binären Output standardisieren, damit man nicht immer seine Lib für tausend Compiler kompilieren bzw ausliefern muss ...
dann reichts das für das jeweilige OS bereitzustellen.
g
-
Scritp0r schrieb:
Man könnte wenigstens mal den binären Output standardisieren, damit man nicht immer seine Lib für tausend Compiler kompilieren bzw ausliefern muss ...
dann reichts das für das jeweilige OS bereitzustellen.
gDer binäre Output ist Sache des Compilers, nicht der Bibliothek. Und gerade die Templates der STL kann man nicht vorkompilieren, daher wird die gleiche Bibliothek bei verschiedenen Compilern auch verschiedenen Output ergeben.
-
pumuckl schrieb:
Scritp0r schrieb:
Man könnte wenigstens mal den binären Output standardisieren, damit man nicht immer seine Lib für tausend Compiler kompilieren bzw ausliefern muss ...
dann reichts das für das jeweilige OS bereitzustellen.
gDer binäre Output ist Sache des Compilers, nicht der Bibliothek. Und gerade die Templates der STL kann man nicht vorkompilieren, daher wird die gleiche Bibliothek bei verschiedenen Compilern auch verschiedenen Output ergeben.
Jo is klar... wegen mir kann ja jeder seine Bibliothek haben, aber es sollte eine Möglichkeit geben, dass zbsp der MinGW auch die ImportLibs des MSVC lesen kann und umgekehrt... das meinte ich
lg
-
Da iss aber ned die STL dran schuld, sondern der C++ Standard, der naemlich den binaeren Aufbau von c++ interfaces / klassen nicht definiert
Deshalb kannst alles vergessen, was klassen exportiert, auch auf anderen compilern laufen zu lassen ...wenn du compilerunabhaengige bibs willst, dann wirst wohl auf C(Interface) zurueckgreifen muessen.
Ansonsten, hoch lebe ein "systemcompiler" ... doof das man dann die meisten binaeries fuer jeden compilertyp besorgen muss, oder auf quellcode angewiesen ist, was der Industrie gar ned gefaellt ...
Ciao ...
-
Es gibt doch Systemcompiler, die Binäre Standards setzen. Wer Linux benutzt, findet mit GCC seinen Systemcompiler. Wer Windows benutzt, findet mit dem MS C++ Compiler seinen Systemcompiler. Und ja, den MS C++ Compiler gibt es im kostenlosen WindowsSDK bei Microsoft zum Download. Die meisten Closedsource-Libs gibts als MS C++ Compiler-Binaries, also kann ich sie auch ungehindert mit dem kostenlosen Systemcompiler benutzen.
Die meisten Libs gibt es im Sourcecode, und dann bin ich meistens sogar frei vom System-Compiler-Zwang. Mit bjam lassen sich solche Libs auch Compiler- und System-neutral bauen. Da brauche ich kein Cygwin oder so.
Übrigens, die STL gibts nur als Templates... wie das T in STL vermuten lässt. Also, was hat das Binär-Interface damit zutun?
Und wer benutzt eigentlich heute die STL, wenn es doch die Standardlib gibt? 
-
Bulli schrieb:
Es gibt doch Systemcompiler, die Binäre Standards setzen. Wer Linux benutzt, findet mit GCC seinen Systemcompiler. Wer Windows benutzt, findet mit dem MS C++ Compiler seinen Systemcompiler. Und ja, den MS C++ Compiler gibt es im kostenlosen WindowsSDK bei Microsoft zum Download.
Auch die "Systemcompiler" ändern ihre ABI oft genug zwischen den Versionen.
Die meisten Closedsource-Libs gibts als MS C++ Compiler-Binaries, also kann ich sie auch ungehindert mit dem kostenlosen Systemcompiler benutzen.
Auch hier muss der Hersteller sie dann für alle Versionen anbieten. Wenn dabei eine fehlt, hat man Pech, bzw. der Hersteller hat Arbeit
Übrigens, die STL gibts nur als Templates... wie das T in STL vermuten lässt. Also, was hat das Binär-Interface damit zutun?
Und wer benutzt eigentlich heute die STL, wenn es doch die Standardlib gibt? Blah. :p
-
Gegen ABI-Änderung hilft unter Windows zumindest COM+.
-
detroit schrieb:
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.
Äh.
OK, nochmal, da du nicht verstanden hast was ich meine. Vielleicht verwende ich die falschen Begriffe, keine Ahnung. Mit "auf lineare Laufzeit (zu) optimieren" meine ich eine Optimierung die an der Komplexität nichts ändert, allerdings das Programm z.B. doppelt so schnell macht (unabhängig von N).Die Checked Iterators zu entfernen ist genau soetwas: es ändert an der Komplexität von operator [] nichts, sehrwohl aber an der Laufzeit.
Jetzt verstanden?
