Warum sind die meisten der größten Open-Source-Projekte in C? [closed]

Lesezeit: 8 Minuten

Benutzer-Avatar
tomzx

Ich habe eine Debatte mit einem Freund und wir fragen uns, warum sich so viele Open-Source-Projekte für C statt für C++ entschieden haben. Projekte wie Apache, GTK, Gnome und andere haben sich für C entschieden, aber warum nicht C++, da es fast dasselbe ist?

Wir suchen genau nach den Gründen, die diese Projekte (nicht nur die, die ich aufgelistet habe, sondern alle C-Projekte) dazu veranlasst hätten, C statt C++ zu verwenden. Themen können Performance, Programmierbarkeit, Debugging, Testing, Konzeption usw. sein.

  • Ein Nit: C++ ist weit, weit, weit entfernt von “fast gleich” wie C.

    – Jed Smith

    11. Oktober 2009 um 21:44 Uhr

  • Sie gingen mit C, weil es zu der Zeit in der Nähe war. C++ ist auch nicht einmal in der Nähe von C.

    – GManNickG

    11. Oktober 2009 um 21:49 Uhr

  • Diejenigen, die darauf abzielen, es als „subjektiv und argumentativ“ zu schließen, sind übermäßig fürsorglich – es wird professionell und nicht argumentativ damit umgegangen.

    – Jonathan Leffler

    11. Oktober 2009 um 21:50 Uhr

  • C wird wahrscheinlich immer noch verwendet, weil es C++ (kein Wortspiel beabsichtigt) übertrifft, was ein Fehler einer Sprache war, und C#, das versuchte, das von C++ verursachte Durcheinander zu beseitigen. Wenn Sie Quellcode aus einer beliebigen Programmiersprache lesen, überprüfen Sie, wie viel Overhead-Text erforderlich ist, um den tatsächlich funktionierenden Code zu unterstützen. C ist sauberer – aber Open-Source-Code ist weit davon entfernt, ein gutes Beispiel für die Verwendung von C zu sein.

    – Ausloggen

    19. Januar 2010 um 1:26 Uhr

Benutzer-Avatar
Gnud

C ist sehr portabel, viel mehr als C++ vor 10 Jahren.

Außerdem ist C sehr in der Unix-Tradition verwurzelt. Lesen Sie mehr in ‘Die Kunst der Unix-Programmierung‘, um Unix und OO im Allgemeinenund über bestimmte Sprachen unter Unix (einschließlich C und C++).

  • Die Links sind sehr schön zu lesen.

    – Pagas

    12. Oktober 2009 um 2:29 Uhr

Benutzer-Avatar
Dirk Edelbüttel

Es gibt zahlreiche Gegenbeispiele: zum einen alles basierend auf Qt.

Auch auf meinem Debian-Testsystem:

edd@ron:~$ apt-cache rdepends libstdc++6|wc -l
4101

Das sind also 4101 Pakete, abhängig von der grundlegenden C++-Bibliothek. Zum Vergleich bekomme ich etwa 14.982 für libc6 oder ungefähr 3,6 so viele. Aber es ist nicht so, wenn es keine C++-Projekte im Open-Source-Land gibt.

Bearbeiten: Thinko meinerseits: Da die C++-Pakete auch von libc6 abhängen, ist das Verhältnis wirklich so

(14982 – 4101)/4101 = 2,65

es sind also etwa 2 1/2 mal so viele Pakete in C implementiert wie in C++.

  • Enthält der 4101 alle von Qt abhängigen Kpackages? 🙂

    – ShreevatsaR

    12. Oktober 2009 um 1:32 Uhr

  • +1 – jemand, der tatsächlich gemessen hat 🙂

    – Johannes Schaub – litb

    12. Oktober 2009 um 13:54 Uhr

Benutzer-Avatar
Alex Martell

Eric Raymonds wunderbares Buch „The Art of Unix Programming“ enthält einige davon Reflexionen zu diesem Thema (es lohnt sich, das ganze Buch in gedruckter oder kostenloser Online-Ausgabe zu lesen, ich weise nur auf den entsprechenden Abschnitt hin — Eric war an der Prägung und Einführung des Begriffs “Open Source” beteiligt und ist es immer sehr lesenswert;-0).

Zusammenfassend behauptet Raymond, dass “OO-Sprachen eine gewisse Tendenz zeigen, Programmierer in die Falle der übermäßigen Schichtung zu saugen” und dass Unix-Programmierer (und im weiteren Sinne Open-Source-Programmierer) dieser Falle des “dicken Klebers” widerstehen.

Später im Buch finden Sie einige Überlegungen speziell zu C++, wie etwa „Es kann sein, dass C++s Realisierung von OO besonders problematisch ist“. Ob Sie zustimmen oder nicht, der gesamte Text ist es wert, gelesen zu werden (ich kann ihm hier kaum gerecht werden!-), und reich an Bibliographien, die Sie auf viele andere relevante Studien und Veröffentlichungen hinweisen.

  • Ich denke, es ist ein fairer Punkt auf OO. Natürlich dreht sich C++ heute viel weniger um OO, und dieser Einwand fällt ziemlich weg, aber als die meisten dieser Projekte (und die Unix-Philosophie) gegründet wurden, war C++ nicht standardisiert und es drehte sich alles um OO.

    – jalf

    11. Oktober 2009 um 22:30 Uhr

  • Ich habe manchmal gesehen, wie sich übermäßig viele Daten verstecken. Eine geringfügige Anforderungsänderung kann zu einem ernsthaften Refactoring führen, oder aus Verzweiflung wird alles öffentlich gemacht. Außerdem kann ich nicht umhin zu bemerken, dass ein wichtiges OOP-Prinzip (oft ausgedrückt als „Du zeichnest nicht die Form, die Form zeichnet sich selbst“) sogar von GOF-Entwurfsmustern verletzt wird. Deshalb ist es mir nicht peinlich, “Tool”-Klassen zu schreiben, die das tun, was sie mit einem anderen Objekt tun. Meiner Meinung nach geht es nur darum, das zu tun, was funktioniert, anstatt Elfenbeintürme zu bauen – OOP sollte als Werkzeugkasten behandelt werden, nicht als Religion.

    Benutzer180247

    12. Oktober 2009 um 3:03 Uhr

  • @jalf: Die Unix-Philosophie wurde einige Jahre vor dem Start von Apache entwickelt …

    – Gnud

    14. Oktober 2009 um 20:35 Uhr

Linus Torvalds hat mehrmals über das Thema C++ gewettert – er verwendet C für Git, und natürlich ist der Linux-Kernel größtenteils C:

Sie können leicht mehr davon finden, und obwohl es in seiner Natur liegt, über diese Dinge ein bisschen flammend zu werden, gibt es einige gültige Punkte.

Eine der interessanteren (jedenfalls aus meiner Sicht) ist die Beobachtung, dass C++-Compiler und -Bibliotheken viel fehlerhafter waren (und bis zu einem gewissen Grad sind) als die entsprechenden C-Compiler. Angesichts der relativen Komplexität der beiden Sprachen liegt dies nahe.

Es riecht ein wenig nach dem „Not-invented-here“ (NIH)-Syndrom, aber wenn man die gesamte Basis der Linux-Kernel-Entwickler hat, kann man es sich manchmal leisten, Dinge „auf die richtige Weise“ neu zu erfinden.

Benutzer-Avatar
Jonathan Leffler

Viele der Projekte begannen, bevor C++ standardisiert wurde, also war C die offensichtliche Wahl und eine spätere Änderung würde schwierig sein. C wurde etwa ein Jahrzehnt vor C++ standardisiert und ist noch länger nahezu portabel. Es war damals also größtenteils eine pragmatische Entscheidung, teilweise inspiriert durch das Unix-Erbe, C für den größten Teil des Codes zu verwenden.

C++ ist ein Chaos. Es ist eine zu komplizierte Sprache, so kompliziert, dass nur wenige Leute sagen können, dass sie alle Teile kennen. Und weniger Compiler, die wirklich dem C++-Standard entsprechen.

Ich denke also, der Grund ist Einfachheit und Portabilität.

Wenn Sie eine übergeordnete und objektorientierte Programmierung wünschen, dann wird C++ meiner Meinung nach nur mit anderen wie Python konkurriert. (Beachten Sie, dass ich einige Jahre in C++ programmiert habe, es ist schnell und hat einige Funktionen aus höheren Sprachen, die die Entwicklung beschleunigen, nichts für ungut.)

Benutzer-Avatar
Karl Norum

Ich habe in meiner Zeit an einigen C++-Projekten gearbeitet, die alle auf die eine oder andere Weise in Tränen geendet haben. Auf der grundlegendsten Ebene ist die Wahrheit, dass Menschen nicht vertraut werden kann. Man kann ihnen nicht vertrauen, dass sie guten Code schreiben, sie können ihnen nicht vertrauen, dass sie ihn debuggen, und ihnen kann man sicherlich nicht vertrauen, dass sie ihn verstehen, wenn sie zurückkommen und ihn Wochen/Monate später erneut modifizieren müssen.

C-Code hat nicht viele der seltsamen Dinge in C++, die das Debuggen erschweren (Konstruktoren/Destruktoren, alles, was mit statischen globalen Objekten während der Zeit von cpp_initialize() passiert, usw.). Das macht es einfach einfacher, mit der Entwicklung und Wartung eines großen Projekts umzugehen.

Vielleicht bin ich ein Maschinenstürmer, aber jedes Mal, wenn jemand in meiner Nähe “C++” sagt, bekomme ich Schauer.

  • Beschissene Entwickler werden in jeder Sprache beschissenen Code schreiben, es ist kaum die Schuld von C++, wenn sie beschissenes C++ schreiben. Ich werde Ihrer Erfahrung widersprechen, indem ich sage, dass jedes C++-Projekt, an dem ich gearbeitet habe, erfolgreich war, das aktuelle etwa 750.000 Codezeilen.

    – Brian Ensink

    11. Oktober 2009 um 21:45 Uhr

  • @Brian: Ich stimme dir zu, aber andererseits würde ich viel lieber mit einem mittelmäßigen C-Programmierer arbeiten als mit einem mittelmäßigen C++-Programmierer. Ein mittelmäßiger C-Programmierer kann brauchbaren Code schreiben. Ein mittelmäßiger C++-Programmierer wird Ihr Programm zum Explodieren bringen. Die steilere Lernkurve könnte ein triftiger Grund für die Bevorzugung von C sein

    – jalf

    11. Oktober 2009 um 22:27 Uhr

  • Ich stimme @Brian im Prinzip zu, aber in der Praxis habe ich einfach zu viele Katastrophen gesehen. Ich sollte nicht sagen, dass die Projekte, an denen ich gearbeitet habe, nicht erfolgreich waren; Eine davon ist ein enormer Erfolg. Leider kann eine RIESIGE Anzahl von Fehlern auf die einfache alte schreckliche Programmierung zurückgeführt werden. Die Tatsache, dass diese schreckliche Programmierung in C++ durchgeführt wurde, machte es nur schwieriger zu debuggen.

    – Karl Norum

    11. Oktober 2009 um 22:39 Uhr

  • Meine Erfahrung mit sehr großen C++-Projekten ist, dass es gut funktioniert, FWIW. Ich würde dringend obligatorische Code-Reviews empfehlen, um die schlechten Dinge frühzeitig zu erkennen.

    – David Thornley

    12. Oktober 2009 um 13:51 Uhr

  • Was passiert, wenn das riesige Projekt als kleines Projekt begann und die Leute einen Haufen Mist geschrieben haben, mit dem wir anderen für alle Ewigkeit leben müssen? Zeit für Refactoring und Verbesserungen des vorhandenen Codes ist das erste, was aus dem Zeitplan gestrichen werden muss, wenn die Frist ihren hässlichen Kopf erhebt.

    – Karl Norum

    12. Oktober 2009 um 16:25 Uhr

1355130cookie-checkWarum sind die meisten der größten Open-Source-Projekte in C? [closed]

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy