Warum ist es wichtig, dass C / C++ Code auf verschiedenen Compilern kompilierbar ist?

Ich interessiere mich für verschiedene Aspekte der Portabilität (wie Sie sehen können, wenn Sie meine anderen Fragen durchsuchen), also lese ich viel darüber. Ziemlich oft lese/höre ich, dass Code so geschrieben werden sollte, dass er auf verschiedenen Compilern kompilierbar ist.

Ohne echte Erfahrung mit gcc / g++ scheint es mir, dass es jede große Plattform unterstützt, die man sich vorstellen kann, sodass Code, der auf g++ kompiliert wird, auf fast jedem System ausgeführt werden kann. Warum sollte sich also jemand die Mühe machen, seinen Code auf dem MS-Compiler, dem Intel-Compiler und anderen ausführen zu lassen?

Ich kann mir auch einige Gründe vorstellen. Wie die FAQ vorschlagen, werde ich versuchen, sie als Antwort zu posten, anstatt sie in meine eigene Frage aufzunehmen.

Bearbeiten: Fazit

Sie haben mich davon überzeugt, dass es mehrere gute Gründe gibt, mehrere Compiler zu unterstützen. Es gibt so viele Gründe, warum es schwierig war, eine Antwort als die akzeptierte auszuwählen. Die wichtigsten Gründe für mich:

• Es ist viel wahrscheinlicher, dass Mitwirkende an meinem Projekt arbeiten oder es einfach verwenden, wenn sie den Compiler ihrer Wahl verwenden können
• Überall kompilierbar zu sein, mit zukünftigen Compilern und Tools verwendbar zu sein und sich an die Standards zu halten, erzwingen sich gegenseitig, also ist es eine gute Idee

Andererseits glaube ich immer noch, dass es andere Dinge gibt, die wichtiger sind, und jetzt weiß ich, dass es manchmal gar nicht wichtig ist.

Und zu guter Letzt gab es keine einzige Antwort, die mich davon überzeugen konnte, GCC nicht als das zu wählen primär oder Ursprünglich Compiler für mein Projekt.

Einige Gründe aus dem Kopf:

1) Um zu vermeiden, an einen einzigen Compiler-Anbieter gebunden zu sein (Open Source oder nicht).

2) Das Kompilieren von Code mit verschiedenen Compilern wird wahrscheinlich mehr Fehler entdecken: Warnungen sind unterschiedlich und verschiedene Compiler unterstützen den Standard in unterschiedlichem Maße.

Es ist gut, auf MSVC kompilierbar zu sein, da einige Leute möglicherweise Projekte haben, die sie in MSVC erstellen und in die sie Ihren Code einbinden möchten, ohne ein völlig anderes Build-System einrichten zu müssen.

Es ist gut, unter dem Intel-Compiler kompilierbar zu sein, da dieser häufig schnelleren Code kompiliert.

Es ist gut, unter kompilierbar zu sein Klirrenweil es bessere Fehlermeldungen ausgeben und eine bessere Entwicklungserfahrung bieten kann, und es ein einfacheres Projekt ist, an dem man arbeiten kann als GCC, und daher in Zukunft möglicherweise zusätzliche Vorteile bietet.

Im Allgemeinen ist es gut, sich die Optionen offen zu halten, denn es gibt keinen Compiler, der alle Anforderungen erfüllt. GCC ist ein guter Compiler und eignet sich für die meisten Zwecke hervorragend, aber manchmal brauchen Sie etwas anderes.

Und selbst wenn Sie normalerweise nur unter GCC kompilieren, hilft es wahrscheinlich auch, sicherzustellen, dass Ihr Code unter anderen Compilern kompiliert wird, um Probleme zu finden, die Ihren Code beispielsweise daran hindern könnten, mit früheren und zukünftigen Versionen von GCC zu funktionieren, falls vorhanden Etwas, bei dem GCC jetzt weniger streng ist, aber später Prüfungen hinzufügt, kann ein anderer Compiler im Voraus erkennen, was Ihnen hilft, Ihren Code sauberer zu halten. Ich fand dies im umgekehrten Fall hilfreich, wo GCC mehr potenzielle Probleme mit Warnungen entdeckte als MSVC (MSVC ist der einzige Compiler, den wir unterstützen mussten, da wir nur unter Windows ausgeliefert haben, aber wir haben eine teilweise Portierung auf den Mac vorgenommen unter GCC in unserer Freizeit), wodurch ich saubereren Code produzieren konnte, als ich es sonst getan hätte.

Portabilität. Wenn Sie möchten, dass Ihr Code für die größtmögliche Anzahl von Personen zugänglich ist, müssen Sie dafür sorgen, dass er auf möglichst vielen Compilern funktioniert. Es ist die gleiche Idee, wie eine Website auf anderen Browsern als IE laufen zu lassen.

Einiges davon ist politisch. Unternehmen haben Standards, Leute haben Lieblingswerkzeuge usw. Jemandem zu sagen, dass er X verwenden soll, schreckt einige Leute wirklich ab und macht es für andere wirklich unzugänglich.

Nemanja bringt auch einen guten Punkt zur Sprache: Das Zielen auf einen bestimmten Compiler zwingt Sie dazu, ihn zu verwenden. In der Open-Source-Welt ist dies möglicherweise kein so großes Problem (obwohl die Leute einfach aufhören könnten, darauf zu entwickeln, und es veraltet ist), aber was ist, wenn das Unternehmen, von dem Sie es kaufen, das Produkt einstellt oder sein Geschäft aufgibt?

Bei den meisten Sprachen kümmere ich mich weniger um die Portabilität als vielmehr um die Einhaltung internationaler Standards oder anerkannter Sprachdefinitionen, aus deren Eigenschaften sich die Portabilität wahrscheinlich ergibt. Für C ist Portabilität jedoch eine nützliche Idee, da es sehr schwierig ist, ein Programm zu schreiben, das “strikt konform” zum Standard ist. (Warum? Weil die Standardisierungsgremien es für notwendig hielten, einige bestehende Praktiken zu übernehmen, darunter auch, den Compilern einige Freiheiten zu geben, die sie vielleicht nicht haben möchten.)

Warum also versuchen, einem Standard zu entsprechen oder Ihren Code für mehrere Compiler akzeptabel zu machen, anstatt einfach zu schreiben, was auch immer gcc (oder Ihr anderer Lieblingscompiler) akzeptiert?

• Wahrscheinlich wird gcc im Jahr 2015 eine ziemlich andere Sprache akzeptieren als heute. Sie würden es vorziehen, Ihren alten Code nicht neu schreiben zu müssen.

• Möglicherweise wird Ihr Code auf sehr kleine Geräte portiert, auf denen die GNU-Toolchain nicht so gut unterstützt wird.

• Wenn Ihr Code kompiliert mit jedem ANSI-C-Compiler direkt aus der Box ohne Fehler und ohne Warnungenwird das Leben Ihrer Benutzer einfacher und Ihre Software kann weithin portiert und verwendet werden.

• Vielleicht erfindet jemand ein großartiges neues Tool zum Analysieren von C-Programmen, Refactoring von C-Programmen, Verbessern der Leistung von C-Programmen oder Finden von Fehlern in C-Programmen. Wir sind nicht sicher, mit welcher Version von C dieses Tool funktioniert oder auf welchem ​​​​Compiler es basiert, aber mit ziemlicher Sicherheit wird das Tool Standard-C akzeptieren.

Von all diesen Argumenten ist es das Tool-Argument, das ich am überzeugendsten finde. Die Leute vergessen, dass man mit Quellcode noch andere Dinge tun kann, als ihn nur zu kompilieren und auszuführen. In einer anderen Sprache, Haskell, hinkten Tools für Analyse und Refactoring weit hinter Compilern hinterher, aber Leute, die am Haskell 98-Standard festhielten, haben Zugriff auf a viel mehr Werkzeuge. Eine ähnliche Situation ist wahrscheinlich für C: Wenn ich mir die Mühe mache, ein Tool zu bauen, werde ich es auf einem Standard mit einer Lebensdauer von etwa 10 Jahren basieren, nicht auf einer gcc-Version, die sich vorher ändern könnte Mein Werkzeug ist fertig.

Allerdings können es sich viele Leute leisten, die Portabilität komplett zu ignorieren. Zum Beispiel habe ich 1995 versucht, Linus Torvalds davon zu überzeugen, es möglich zu machen, Linux mit jedem ANSI-C-Compiler zu kompilieren, nicht nur mit gcc. Linus hatte überhaupt kein Interesse – ich vermute, er kam zu dem Schluss, dass nichts für ihn oder sein Projekt dabei wäre. Und er hatte recht. Linux nur mit gcc kompilieren zu müssen, war ein großer Verlust für Compiler-Forscher, aber kein Verlust für Linux. Das „Tool-Argument“ galt nicht für Linux, weil Linux so unglaublich populär wurde; Leute, die Analyse- und Bug-Finding-Tools für C-Programme entwickelten, waren bereit, mit gcc zu arbeiten, weil der Betrieb unter Linux es ihrer Arbeit ermöglichen würde, große Auswirkungen zu haben. Wenn Sie sich also darauf verlassen können, dass Ihr Projekt ein voller Erfolg wird wie Linux oder Mosaic/Netscape, können Sie es sich leisten, Standards zu ignorieren 🙂

Wenn Sie für verschiedene Plattformen erstellen, werden Sie am Ende verschiedene Compiler verwenden. Darüber hinaus neigen C++-Compiler dazu, immer etwas hinter dem C++-Standard zu sein, was bedeutet, dass sie ihre Einhaltung im Laufe der Zeit normalerweise ändern. Wenn Sie den gemeinsamen Nenner auf alle großen Compiler abzielen, werden die Wartungskosten für den Code niedriger sein.

Bei Anwendungen (insbesondere Open-Source-Anwendungen) kommt es häufig vor, dass andere Entwickler andere Compiler verwenden möchten. Einige würden lieber Visual Studio mit MS Compiler für Entwicklungszwecke verwenden. Einige würden lieber den Intel-Compiler für behauptete Leistungsvorteile und dergleichen verwenden.

Also hier sind die Gründe, die ich mir vorstellen kann

• wenn Geschwindigkeit das größte Anliegen ist und es für einige Plattformen spezielle, hochoptimierte Compiler gibt
• wenn Sie eine Bibliothek mit einer C++-Schnittstelle erstellen (Klassen und Templates, statt nur Funktionen). Aufgrund von Namensverstümmelungen und anderen Dingen muss die Bibliothek mit demselben Compiler kompiliert werden wie der Client-Code, und wenn der Client Visual C++ verwenden möchte, muss er in der Lage sein, die Lib damit zu kompilieren
• wenn Sie eine sehr seltene Plattform unterstützen möchten, die keine gcc-Unterstützung hat

(Für mich spielen diese Gründe keine Rolle, da ich eine Bibliothek bauen möchte, die intern C++ verwendet, aber eine C-Schnittstelle hat.)