Codequalität in Open Source Projekten

SeppJ

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_cast gesagt zu haben. Hat irgendjemand das mal vorgeschlagen, um irgendeine triviale Aufgabe zu lösen?

Sone

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_cast gesagt 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.

Mechanics

Boost interessiert mich in dem Zusammenhang nicht. Da kann man natürlich drüber streiten. Mir gings eher um Anwendungssoftware, nicht um Basisbibliotheken.

The Battle for Wesnoth fand ich ganz gut gemacht.

Closed Source ist doch genauso schlimm!

TyRoXx

not wes schrieb:

The Battle for Wesnoth fand ich ganz gut gemacht.

Die Codings Standards haben mich sehr überrascht. Da wird anscheinend wirklich C++ benutzt. Wo C++ drauf steht, sind normalerweise schlechtes C mit Klassen und Spaces zum Einrücken drin.

Geht es dir jetzt ausschließlich um C++? Viele der Open-Source-Projekte, die heute formal in C++ geschrieben sind, basieren ursprünglich auf einer C-Codebasis. Da braucht man sich natürlich nicht wundern, wenn der Großteil des Codes kein modernes C++ ist. Bei deinem MariaDB-Beispiel ist zu beachten, dass z.B. die STL erst seit Version 10.0 überhaupt genutzt wird.

Bind 10 könntest du dir mal ansehen. Soweit ich weiß wurde dort viel Legacy-C-Code über Bord geworfen und in C++ neugeschrieben.

Sone schrieb:

Merkwürdig. Du willst mir doch nicht erzählen, dass die Einzigen, bzw. ein Großteil derer die solche Konzepte konsequent umsetzen und lernen hier im Forum anzutreffen sind?

Du musst bedenken, dass die Konzepte, die hier gelehrt werden im C++-Stil von 2013 sind. Oder sagen wir 2012. Die Projekte von Mechanics haben noch vor C++98 angefangen und schlechtes C++ wirkt sich viral aus, nachträglich RAII reinflicken ist schwer.

hustbaer

Gerade RAII ist nachträglich oft sehr leicht "reinzuflicken". Aber egal.

Zum eigentlichen Thema...

Crypto++ finde ich gut. Nicht so ultramodernes C++, aber sehr aufgeräumt, sehr konsequent durchgezogen, alles gut aus einem Guss.

Die Teile von foobar2000 die ich mir mal angesehen hatte haben auch sehr aufgeräumt und konsequent gewirkt.

"Teile von" Boost wurde schon erwähnt. Wobei ich sogar sagen würde dass es kaum Boost Libraries gibt die nicht sauber implementiert wären. Viele Boost Libs sind ziemlich schlecht zu lesen, aber das liegt zu einem grossen Teil an...
* Sie versuchen mit C++ Dinge zu machen für die C++ nie ausgelegt war und die sich daher einfach sehr wehren.
* Sie haben haufenweise Workarounds für diverse Compiler-Bugs drinnen
* Sie werden von Leuten entwickelt die einfach auf einem sehr hohen Niveau arbeiten, und weniger Wert darauf legen dass der Code von Leuten mit weniger guten C++ Skills leicht verstanden werden kann als auf gute Verwendbarkeit, Vollständigkeit, DRY etc.

ASIO und GIL sollten vielleicht noch extra erwähnt werden da sie ursprünglich ausserhalb von Boost entwickelt wurden und dann erst später übernommen. Auch beide sehr sauber implementiert.

Ich bin jetzt zwar nicht der grösste ASIO Fan, aber das liegt nicht an der QOI sondern eher an Designentscheidungen. Was mich gleich zu lexical_cast bringt: die Implementierung von lexical_cast ist schwer OK, und auch recht gut optimiert soweit ich erkennen konnte. Das Problem von lexical_cast ist eher dass Leute es für Dinge verwenden wo es nicht angebracht ist. Man kann natürlich die grundlegende Designentscheidung "jede Konvertierung findet über Stream-Insert gefolgt von Stream-Extraction statt" in Frage stellen. Wenn man diese aber akzeptiert, dann kann man die Implementierung mMn. nicht wirklich schlecht nennen. Und dann darf man sich auch nicht aufregen, dass lexical_cast<double>(42) ca. 1.000.000 mal (grobe Schätzung) langsamer ist als ein static_cast . Und wenn man diese grundlegende Designentscheidung nicht akzeptiert, dann sollte man verdammt nochmal was anderes verwenden.

Weiss nicht ob Qt im Sinne des Fragestellers als "Open Source" zu zählen ist, aber da der Source frei zugänglich ist würde ich es mal so nennen. Ist zwar überhaupt nicht modern, aber auch ziemlich aufgeräumt und sauber implementiert.

Und weil ich schon so viele Libraries aufgezählt habe sollte Loki auch nicht fehlen.

Ethon

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_cast gesagt 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*

otze

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?

Sone

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.

cooky451

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.

Ethon

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.

hustbaer

Lol. Ihr seid schon ein lustiger Haufen. Nehmt was anderes wenn euch lexical_cast zu langsam ist.

Wenn man grosse Textfiles zu parsen hat, dann kann es vorkommen dass sogar das Rausschneiden der einzelnen Teile als eigene std::string schon zu lange dauert.
Da werdet ihr dann aber sicher auch noch lexical_cast verwenden. Und schuld dass es langsam ist seid dann auch nicht ihr, sondern lexical_cast , weil wegen dem müsst ihr ja überhaupt erst die kleinen Teilstrings als std::string rausschneiden.

http://www.heise.de/developer/meldung/Studie-Open-Source-und-proprietaere-Software-qualitativ-gleichauf-1857652.html

Mechanics

studienfälscher schrieb:

http://www.heise.de/developer/meldung/Studie-Open-Source-und-proprietaere-Software-qualitativ-gleichauf-1857652.html

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.