Das sind Fehler die erst gefunden wurden als die Software massenhaft eingesetzt wurde. Die Billiarden Zeilen Code die GCC 4.5 sauber übersetzt hat siehst du ja nicht. Mir ist in den letzten drei Monaten beim Einsatz von GCC 4.5.0 z.B. nicht ein einziger dieser Fehler begegnet, und Ich übersetze Brocken wie KDE oder Wine damit.
Zudem befreit eine Versionspolitik den Nutzer nicht davon seinen Hausverstand einzusetzen.
Die Freigabe erfolgte aber mit dem Wissen, dass Fehler existieren. Man könnte auch versuchen, den Fehlern nachzugehen, statt zu hoffen, dass die nicht mehr auftreten bzw. keiner sich mehr darüber beschwert.
PS: Oder gleich den Compiler als experimentiell zu brandmarken.
Nicht jeder Fehler kann ohne weiteres gelöst werden. Teils verlassen sich Programme auf ein bestimmtes – wenn auch fehlerhaftes – Verhalten, oder die Lösung würde zu anderen Nachteilen führen, die man nicht eingehen will. Das muss hier nicht so sein, aber war in der Vergangenheit beim gcc der Fall.
Spätestens beim Einsatz unter MinGW mit aktivierten SSE-Instruktionen bekommst du nur Probleme wegen fehlausgerichteter Daten auf dem Stack - der produzierte Code führt dann in schöner Regelmäßigkeit zu Abstürzen. Der Fehler ist bekannt, die GCC-Entwickler haben aber verschiedene Patches zurückgewiesen und wollen selber offenbar auch nicht tätig werden. Noch schlimmer wirds, wenn man den tree-vectorizer anschaltet. Kann mir einer sagen, was er will, das ist wieder mal typisch OpenSource-Gefrickel..
Bei einem Projekt wie dem GCC sind das nicht viele Fehler. Die Qualität ist eher nicht gesunken. Natürlich gibt es im GCC zig Fehler, aber es kommt halt darauf an wo diese Fehler sind z.B. würde eine Fehler beim Übsetzen für Itanium nicht vielen Leuten auffallen.
Natürlich ist es möglich die Zahl der Fehler noch weiter zu reduzieren, aber das würde erheblich mehr Zeit kosten. Wer will schon ein paar Jahre auf die nächste Version warten?
Und wieder einmal hat sich vermutlich die Kompilergeschwindigkeit halbiert.
Macht endlich hinne mit dem PCC, ist schon unglaublich das es keine freie Alternative zu GCC fuer die 90% aller Faelle gibt wo GCC gar nicht benoetigt wird.
Ist doch war der ist so lahm das ist nicht zum aushalten. Insbesondere bei reinem C ist der msvc von Microsoft fast 15x schneller. Und in 99% aller Faelle sind die gcc features wie schnelle Compilate ueberfluessing.
Einen GCC brauechte ich jeden Monat nur einmal um das Release zu kompilieren. Zwischendruch einen schnellen reinen C Compiler. Das ist es.
Aber heute nacht hab ich mir PCC angesehen, Gott das ist immer noch voellig untauglich unter Linux/MacOSX.
Wenn du den Code und deine Makefiles richtig organisierst, dann gibt es kaum Unterschiede zu den anderen Compilern. Faustregel: Kleine Units! Nur das Nötige #includen.
Ein größeres Problem stellt das Linken dar, und ich glaube, die meisten Programmierer, die über die Geschwindigkeit von g++ meckern, meckern eigentlich über ld, wissen es aber nur nicht. ld ist aber nicht g++, und lässt sich auch mit dem gold-linker substituieren.
1. Ist der nicht fertig. Es fehlt immer noch der letzte (bezahlte) Stufe oder irre ich mich da? 2. Ist der fast komplett neu geschrieben, mit heißer Nadel. 3. Ist der ein reiner C-Compiler für eine Hand voll Plattformen.
"und auch die Anzahl der mittelschweren Fehler mit Priorität P2 hat sich von 103 auf 99 verringert"
Ja das ist doch mal ein Grund zum Feiern!
Die GCC stand schon immer für Qualität.
Warum wird der Kram eigentlich freigegeben, wenn noch so viele Fehler drin sind?
Das sind Fehler die erst gefunden wurden als die Software massenhaft eingesetzt wurde. Die Billiarden Zeilen Code die GCC 4.5 sauber übersetzt hat siehst du ja nicht. Mir ist in den letzten drei Monaten beim Einsatz von GCC 4.5.0 z.B. nicht ein einziger dieser Fehler begegnet, und Ich übersetze Brocken wie KDE oder Wine damit.
Zudem befreit eine Versionspolitik den Nutzer nicht davon seinen Hausverstand einzusetzen.
Die Freigabe erfolgte aber mit dem Wissen, dass Fehler existieren. Man könnte auch versuchen, den Fehlern nachzugehen, statt zu hoffen, dass die nicht mehr auftreten bzw. keiner sich mehr darüber beschwert.
PS: Oder gleich den Compiler als experimentiell zu brandmarken.
Nicht jeder Fehler kann ohne weiteres gelöst werden. Teils verlassen sich Programme auf ein bestimmtes – wenn auch fehlerhaftes – Verhalten, oder die Lösung würde zu anderen Nachteilen führen, die man nicht eingehen will.
Das muss hier nicht so sein, aber war in der Vergangenheit beim gcc der Fall.
Spätestens beim Einsatz unter MinGW mit aktivierten SSE-Instruktionen bekommst du nur Probleme wegen fehlausgerichteter Daten auf dem Stack - der produzierte Code führt dann in schöner Regelmäßigkeit zu Abstürzen. Der Fehler ist bekannt, die GCC-Entwickler haben aber verschiedene Patches zurückgewiesen und wollen selber offenbar auch nicht tätig werden. Noch schlimmer wirds, wenn man den tree-vectorizer anschaltet. Kann mir einer sagen, was er will, das ist wieder mal typisch OpenSource-Gefrickel..
Bei einem Projekt wie dem GCC sind das nicht viele Fehler. Die Qualität ist eher nicht gesunken. Natürlich gibt es im GCC zig Fehler, aber es kommt halt darauf an wo diese Fehler sind z.B. würde eine Fehler beim Übsetzen für Itanium nicht vielen Leuten auffallen.
Natürlich ist es möglich die Zahl der Fehler noch weiter zu reduzieren, aber das würde erheblich mehr Zeit kosten. Wer will schon ein paar Jahre auf die nächste Version warten?
Ist das jetzt dein erst?
Und wieder einmal hat sich vermutlich die Kompilergeschwindigkeit halbiert.
Macht endlich hinne mit dem PCC, ist schon unglaublich das es keine freie Alternative zu GCC fuer die 90% aller Faelle gibt wo GCC gar nicht benoetigt wird.
???
zum Beispiel?
Ist doch war der ist so lahm das ist nicht zum aushalten. Insbesondere bei reinem C ist der msvc von Microsoft fast 15x schneller. Und in 99% aller Faelle sind die gcc features wie schnelle Compilate ueberfluessing.
Einen GCC brauechte ich jeden Monat nur einmal um das Release zu kompilieren. Zwischendruch einen schnellen reinen C Compiler. Das ist es.
Aber heute nacht hab ich mir PCC angesehen, Gott das ist immer noch voellig untauglich unter Linux/MacOSX.
Kannst du deine wilden Behauptungen auch mit konkreten Beispielen / Benchmarks belegen?
Schon mal mit -O0 versucht und -O3 abgeschaltet?
Wenn du den Code und deine Makefiles richtig organisierst, dann gibt es kaum Unterschiede zu den anderen Compilern. Faustregel: Kleine Units! Nur das Nötige #includen.
Ein größeres Problem stellt das Linken dar, und ich glaube, die meisten Programmierer, die über die Geschwindigkeit von g++ meckern, meckern eigentlich über ld, wissen es aber nur nicht. ld ist aber nicht g++, und lässt sich auch mit dem gold-linker substituieren.
1. Ist der nicht fertig. Es fehlt immer noch der letzte (bezahlte) Stufe oder irre ich mich da?
2. Ist der fast komplett neu geschrieben, mit heißer Nadel.
3. Ist der ein reiner C-Compiler für eine Hand voll Plattformen.
Seit wann kann denn der MSVC reines C?
Der MSC kann zumindest C89. C98 kann er nicht.
C98 gibts nicht. Du meinst C99.
Der Omega13.
Deswegen ist der MSVS Compiler Schrott.
Ich brauche ständig C99.
Allein schon wegen long long Integervariablen, dem // Kommentarzeichen und der Möglichkeit Variablen z.B. innerhalb der For Schleife zu definieren.
Das gibt's, wenn es standardisiert sein soll, alles erst ab C99.
@Lothar: hast du dir schon mal llvm angeschaut? C++ kann der noch nicht 100%ig, aber C scheint ziemlich gut zu laufen.
Wie kommst du darauf dass LLVM und clang ausgereifter ist?
Wie kommst du darauf, dass ich darauf komme
Er hat nach einem schnellen C Compiler gefragt und ich hab etwas in die Runde geworfen, was bisher noch nicht erwähnt wurde.