Warum schreibt jeder Compiler hersteller seine eigene Standardlibrary?

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.

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!

hustbaer

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

pumuckl

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

Der 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.
g

Der 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

RHBaum

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?

LordJaxom

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