Codequalität in Open Source Projekten
-
Sone schrieb:
SeppJ schrieb:
Sone schrieb:
Edit: Und hier im Forum ist ja auch der Overhead durch die ganze Boost Architektur verpönt... wie war das nochmal mit
boost::lexical_cast, SeppJ?Ich kann mich nicht erinnern, jemals irgendetwas zu
boost::lexical_castgesagt zu haben. Hat irgendjemand das mal vorgeschlagen, um irgendeine triviale Aufgabe zu lösen?Tut mir Leid, war Ethon:
2. Bezweifle ich, lexical_cast ist langsam wie eingeschlafene Füße, dank dem Designfetisch der Boost Devs.
Ja, weil lexical_cast<string, int> bzw lexical_cast<int, string> beträchtlich langsamer als atoi/itoa sind, obwohl man einfach die Funktion für alle möglichen Typen performant überladen hätte können.
--
Und zu hustbaers Einwand: Bis vor einer Weile war boost::lexical_cast noch die Standardlösung für int/float <=> string Konvertierungen, es gab einfach nichts anderes "Fertiges" in der Standardbibliothek/Boost außer den Streams (Die viel zu lahm für solche trivialen Aufgaben sind) und den C-Funktionen (Die zu fricklig sind).
... ah ne, Boost.Spirit gäb's noch. *hust*
-
Ethon schrieb:
Ja, weil lexical_cast<string, int> bzw lexical_cast<int, string> beträchtlich langsamer als atoi/itoa sind, obwohl man einfach die Funktion für alle möglichen Typen performant überladen hätte können.
http://www.boost.org/doc/libs/1_53_0/doc/html/boost_lexical_cast/performance.html
wo sehe ich denn hier das Geschwindigkeitsproblem?
Oder warum sehe ich es nicht?
-
otze schrieb:
Ethon schrieb:
Ja, weil lexical_cast<string, int> bzw lexical_cast<int, string> beträchtlich langsamer als atoi/itoa sind, obwohl man einfach die Funktion für alle möglichen Typen performant überladen hätte können.
http://www.boost.org/doc/libs/1_53_0/doc/html/boost_lexical_cast/performance.html
wo sehe ich denn hier das Geschwindigkeitsproblem?
Oder warum sehe ich es nicht?Genau der Grund wieso ich es damals sagte.
-
otze schrieb:
wo sehe ich denn hier das Geschwindigkeitsproblem?
Oder warum sehe ich es nicht?Der Vergleich ist nur leider einigermaßen nutzlos, weil sie strtol/strtod gar nicht mit getestet haben.
-
Da gab es imho auch einen Vergleich mit optimierten Versionen und die waren sehr, sehr viel schneller. Und wenn man viel konvertieren muss (zb. beim Lesen/Schreiben einer Datenbank-XML-Datei) fällt das durchaus ins Gewicht, wenn lexical_cast da miittelmäßig herumgurkt.
-
Lol. Ihr seid schon ein lustiger Haufen. Nehmt was anderes wenn euch
lexical_castzu langsam ist.Wenn man grosse Textfiles zu parsen hat, dann kann es vorkommen dass sogar das Rausschneiden der einzelnen Teile als eigene
std::stringschon zu lange dauert.
Da werdet ihr dann aber sicher auch nochlexical_castverwenden. Und schuld dass es langsam ist seid dann auch nicht ihr, sondernlexical_cast, weil wegen dem müsst ihr ja überhaupt erst die kleinen Teilstrings alsstd::stringrausschneiden.
-
-
studienfälscher schrieb:
Der Vergleich zwischen Open Source und kommerziell bringt nichts. Und die Anzahl der Fehler sagt auch sehr wenig über die Codequalität aus. Wir arbeiten an einer kommerziellen Software mit allein 6 Mio Zeilen C++ Code. Objektiv gesehen ist der Code nicht gut. Aber er wird immer besser
Und wir haben wahrscheinlich viel mehr Fehler, als in der Studie angegeben. Aber die interessieren nicht so sehr, weil wir keine Software für den Massenmarkt schreiben. Die Software ist einfach viel zu groß für das relativ kleine Team und die meisten Komponenten sind bei weitem nicht perfekt. Um das ganze fehlerfrei zu bekommen (allein die Fehler, die uns eh schon bekannt sind, und das sind tausende oder zehntausende), müsste man in jede einzelne Komponente nochmals sehr viel Zeit reinstecken. Lohnt sich aber nicht, weil die gut genug funktionieren und die Kunden damit arbeiten können. Sagt jetzt also gar nichts über die Qualität aus.
-
Mechanics schrieb:
Und die Anzahl der Fehler sagt auch sehr wenig über die Codequalität aus.
Sie sagt aus, wie aktiv das Projekt ist. COBOL-Code ist praktisch fehlerfrei.
Neben allgemeinem Bashing von Open-Source-Code erwähnt der Artikel, dass die Anzahl Zeilen der FLOSS-Projekte massiv gestiegen ist.
-
Mechanics schrieb:
Nur mal so am Rande... Ich will hier jetzt nicht den nächsten Trollkrieg-Thread erstellen, aber... Was haltet ihr so von den gängigen Open Source Projekten und kennt ihr Open Source Projekte, die in sauberem C++ geschrieben sind?
Ich hab mir in letzter Zeit aus paar Interesse paar Projekte grob angeschaut und war von keinem wirklich angetan. z.B. MariaDb, Scribus, Abiword, Incscape. Ich hätt gedacht, MariaDb wär in C geschrieben, war etwas überrascht, dass es doch C++ ist, hab dann reingeschaut, und das schaut schon sehr C-lastig aus.
Bei anderen Projekten auch so ähnlich. Sowas wie Methoden, die einen void Parameter bekommen hab ich ständig gesehen (ich glaub, das macht sogar VS automatisch, hab den Assisten ewig nicht mehr verwendet), char* wo es auch ein std::string tun würde, mit const correctness und ohne wild gemischt... Ewig große Dateien mit 10 000+ Zeilen usw. Smart pointer oder generell raii Konzepte habe ich nirgends gesehen. Bei MariaDb hatte ich eher den Eindruck, dass Klassen einen parameterlosen Konstruktor und eine zusätzlich nach_c_ausschauende_init_methode mit vielen Parametern haben.
Ich sag ja nicht mal was über die Architektur, da kann man sich in paar Minuten durchschauen keine Meinung bilden, aber zumindest die äußere Form hat mich jetzt bei keinem von den paar Projekten überzeugt.Dafür gibt es eine einfache Erklärung:
1. Bei Open Source Projekten programmieren viele alte Hasen mit, die C++ noch von C her gelernt haben.
2. Bei Open Source Projekten mischen viele junge Programmierer mit, die C++ noch nicht gut genug können und zum Lernen das falsche C++ gekauft und gelesen haben. (möglicherweise eines, von den alten Hasen, die in C denken)
3. Manche Open Source Projekte sind über die Jahre gewachsen, da ist es kein Wunder, dass sich darin noch alter C Style Code befindet.Um hier also guten Code zu finden müßtest du nach folgenden Kriterien suchen:
1. Die Entwickler müssen erfahren genug, aber nicht zu alt bzw. von vorgestern sein. Die dürften neuen C++ Stil dann anwenden.
2. Das Open Source Projekt sollte neu sein und auf keinem alten Code aufbauen,. Also ein Alter von höchstens < 5 Jahren.
3. Das Projekt sollte nicht zu einfach sein, so dass unerfahrene Newbies erst gar nicht in die Quere kommen.Wenn diese drei Punkte zutreffen, ja, dann steigen deine Chancen sauberen modernen C++ Code zu finden.
-
Ergänzungskorrektur:
Programmierfachprofi schrieb:
2. Bei Open Source Projekten mischen viele junge Programmierer mit, die C++ noch nicht gut genug können und zum Lernen das falsche C++
Buch
gekauft und gelesen haben.
-
Programmierfachprofi schrieb:
1. Bei Open Source Projekten programmieren viele alte Hasen mit,
2. Bei Open Source Projekten mischen viele junge Programmierer mit, 
-
nachdem ich inzwischen den code von einigen kommerziel verkauften softwareprodukten kenne, die in ihrem bereich durchaus als gut gelten, kann ich dir sagen:
der code ist trotzdem nicht gerade schön. aber er ist seit jahren im einsatz und funktioniert!es glaubt halt jeder programmierer, der code sieht, dies und jenes könnte ich besser machen.
er sieht aber nicht, dass viele komische konstrukte erst entstanden sind, weil immer wieder bugs gefixt worden sind, oder weil durch alte compilerversionen gewisse dinge nicht anders möglich waren, oder was weiß denn ich.
im nachhinein code schlechtreden ist immer einfach. ihn selbst zu schreiben und soweit zu bekommen, dass er wirklich fehlerfrei läuft, ist hingegen viel aufwendiger.Mechanics, ich denke dir fehlt einfach noch die erfahrung, um zu merken, dass der code vielleicht gar nicht so schlecht ist.
nur weil nicht überall alle konzepte von Scott Meyers verwendet werden, heißt das nicht automatisch, dass der code schrott ist. schau dir ein source file auch mal historisch gesehen an. vielleicht gabs shared_ptr und ähnliches zu dem zeitpunkt ja noch garnicht? gerade wenn man verschiedene plattformen und compiler unterstützen möchte (ja, es gibt mehr als Windows!), entdeckt man immer wieder mal unschöne probleme.
-
dfsdfs schrieb:
Mechanics, ich denke dir fehlt einfach noch die erfahrung, um zu merken, dass der code vielleicht gar nicht so schlecht ist.
Du interpretierst da zu viel rein. Ich arbeite seit Jahren als Softwareentwickler an großen Projekten, ich meine schon, etwas Erfahrung zu haben
Und ich kann durchaus mit nicht optimalem Code leben. Hab glaub schon öfter gesagt, dass unser Code in der Arbeit objektiv gesehen nicht schön ist. Ich kenne da auch sehr viele Konstrukte, die vor 10-15 Jahren entstanden sind und mittlerweile entsprechend gewachsen sind.
Und ich war auch nicht "überrascht" über die schlechte Qualität in Open Source Projekten, und wollte den Code auch nicht schlecht reden. Mir gings zum einen darum, ob jemand entsprechend sauber aufgebaute Projekte kennt (da wurden jetzt paar Beispiele genannt, aber nichts größeres, außer Qt, das kenn ich auch selber sehr gut), und zum anderen ging es mir auch darum, ob vielleicht jemand eine andere Meinung über die von mir genannten Projekte hat. Ich habe mir den Code ja nur ganz grob angeschaut. Hätte ja sein können, dass jemand sagt, nein, MySql kenn ich sehr gut, schaut oberflächlich zwar nach C aus, hat intern aber eine sehr durchdachte Architektur und ein paar sehr elegante Ansätze/Lösungen.
-
Mechanics schrieb:
Was haltet ihr so von den gängigen Open Source Projekten und kennt ihr Open Source Projekte, die in sauberem C++ geschrieben sind?
Ich glaube ich habe noch kein C++-Projekt gesehen (weder closed- noch open-source), bei dem ich dachte, der Code ist jetzt schoen oder sauber.
C++ und "schoen" schliesst sich eh quasi aus (siehe boost... das Ergebnis schaetze ich zwar sehr, aber der Code ist geradezu absurd laecherlich kompliziert).
Oder das bereits genannte Qt. Das ist zwar sauber und ordentlich, aber aus C++-technischer Sicht total-fail wegen dem MOC, der das ganze Gebilde nochmal komplizierter macht. Zumal die Kern MOC-Funktionalitaet heutzutage mit boost::function viel besser geht.
Schoenen Code findet man dagegen bei vielen OpenSource C-Projekten (zumindest bei moderneren wie Gnome, aber auch einigen alten wie emacs).
-
Radiopot schrieb:
Das ist zwar sauber und ordentlich, aber aus C++-technischer Sicht total-fail wegen dem MOC,
Es ist immer hochintelligent, Abkürzungen vor der Nennung des ausgeschriebenen Fachbegriffs zu benennen, da weiß gleich jeder worum es geht.
-
MOC =Missle Offensive CPU schrieb:
Radiopot schrieb:
Das ist zwar sauber und ordentlich, aber aus C++-technischer Sicht total-fail wegen dem MOC,
Es ist immer hochintelligent, Abkürzungen vor der Nennung des ausgeschriebenen Fachbegriffs zu benennen, da weiß gleich jeder worum es geht.
Da bin ich mir nicht sicher. Wenn man Qt MOC noch nicht gehoert hat, hat man womoeglich auch QT noch nicht gehoert. Dann muss man sich jetzt eh selbst schlau machen. Zumal Meta-Object-Compiler jetzt auch nichts darueber aussagt, inwiefern sich das auf den eigentlichen C++ Code auswirkt (naemlich in diesem Fall, schlecht).
-
Radiopot schrieb:
Oder das bereits genannte Qt. Das ist zwar sauber und ordentlich, aber aus C++-technischer Sicht total-fail wegen dem MOC, der das ganze Gebilde nochmal komplizierter macht. Zumal die Kern MOC-Funktionalitaet heutzutage mit boost::function viel besser geht.
Das wäre aber schrecklich, wenn man für Qt auch noch boost bräuchte. Wenn dann, sollte man das schon mit C++(11) Sachen machen.
