Die Programmiersprache C (Probleme der C-Sprache)
(hut.mearie.org)-
Speicherprobleme: Keine Unterstützung durch Werkzeuge wie GC oder statische Analyse.
-
Undefiniertes Verhalten: C wird vor allem in Low-Level-Umgebungen eingesetzt, in denen hohe Anforderungen an Optimierung bestehen, und zur Optimierung hat die Menge an undefiniertem Verhalten zugenommen. Es gelingt nicht, gleichzeitig Low-Level-Performance und Portabilität zu erreichen.
-
Für groß angelegte Programmierung ungeeignet: Fehlen von Modulen und Paketmanagern. Selbst weit verbreitete Dinge wie
#pragma oncesind nicht standardisiert.
7 Kommentare
Vielen Dank fürs Teilen des guten Artikels. Allerdings gibt es einen kleinen Punkt, der mich etwas stutzig gemacht hat, daher hinterlasse ich diesen Kommentar.
Ich bin der Verfasser des Artikels (haha ...). Da sich die Website derzeit in einem Soft-Release-Zustand befindet und ich testweise Inhalte verfasse, bitte ich um Verständnis, dass der Inhalt fortlaufend geändert werden kann. Ich verfolge das zwar auch selbst direkt, aber Sie können mir gern auch per E-Mail Feedback schicken.
Wie Sie sagen, wirkt vcpkg derzeit wie der vielversprechendste Paketmanager, und Conan ist tatsächlich ebenfalls ein Projekt, das es schon seit ziemlich langer Zeit gibt (also nicht besonders weit vom Zeitpunkt der ursprünglichen Abfassung entfernt). Das wichtigste Merkmal dieser Projekte ist jedoch, dass sie selbst kein Build-System besitzen, sondern Meta-Build-Systeme sind. (Wenn man bedenkt, dass CMake selbst, eines ihrer wichtigsten Zielsysteme, bereits ein Meta-Build-System ist, könnte man fast von einem Meta-Meta-Build-System sprechen ...). Daher ist es schwierig, Probleme zu lösen, die unmittelbar durch das Build-System selbst entstehen. Bei vcpkg sieht man Spuren, dass darüber etwas stärker nachgedacht wurde; wenn beispielsweise in einem Projekt unterschiedliche Versionen derselben Abhängigkeit benötigt werden (über verschiedene Abhängigkeitspfade), kann man das Enlistment aufteilen. Das ist jedoch letztlich nur eine Methode, die Grenzen des Build-Systems selbst zu umgehen. Bei Rust und Cargo etwa werden in einem solchen Fall einfach beide Versionen gebaut, und es ist kein Problem, sie innerhalb eines Crate zu referenzieren.
Außerdem scheint vcpkg derzeit in Visual Studio nicht einmal eine Tool-Integration auf NuGet-Niveau zu haben (nur MSBuild-Integration ...), und auch die Integration mit den Paketmanagern von Linux-/BSD-Distributionen scheint nicht besonders weit zu sein. Dieses Problem ist derzeit überhaupt eines der größten, mit denen sprachspezifische Paketmanager konfrontiert sind; neuere Sprachen wie Rust lösen es nach und nach im Alleingang, aber ein Paketmanager für C/C++ müsste eigentlich unbedingt die Integration mit bestehenden Systemen anstreben, und genau das kommt bislang nur schleppend voran. Erst wenn dieser Teil gelöst ist, kann man sagen, dass Systeme der Art von vcpkg in der C/C++-Entwicklung allgemein als nutzbare Werkzeuge gelten können. Dass das noch nicht der Fall ist, ist der Hauptgrund, warum ich Paket-Systeme in meinem Artikel eher niedrig bewertet habe. (Dass sich die im Artikel erwähnten Single-File-Libraries so stark verbreiten, ist indirekt ebenfalls ein Beleg dafür, dass Systeme vom Typ vcpkg nicht besonders überzeugend wirken.)
Vielen Dank für die ausführliche Antwort. Letztlich ist die Grundlage eben = m =.. der Build-Prozess, daher gibt es im Unterschied zu npm oder anderen Paketmanagern wohl eine Grenze, die man nicht überwinden kann. Bei vcpkg scheint man sich in letzter Zeit viele Gedanken über Versionen zu machen, aber das wird wohl nicht leicht zu lösen sein.
Ich frage mich auch, ob das Modulsystem von C++20 nicht eine Antwort auf dieses Problem sein könnte ... aber dann würde der Rahmen über die C-Sprache hinausgehen (...). Für C scheint dann wohl nur noch ein steiniger Weg übrig zu bleiben. Selbst wenn man jetzt noch C20 standardisieren würde, wäre die Umstiegsquote vermutlich nicht so hoch wie bei C++..
Vielen Dank für die gute Meinung.
Meine persönliche Ansicht ist folgende: Dass es einige C-Paketmanager gibt, ist eine gute Entwicklung, aber das Problem scheint zu sein, dass diese Paketmanager nicht weit verbreitet genutzt werden. Genauer gesagt denke ich, dass wir wegen des enormen Legacy-Bestands von C vielleicht schon zu weit gekommen sind, um die oben genannten Probleme noch zu lösen. Deshalb gibt es vermutlich auch so viele Versuche, auf neue Sprachen wie Rust umzusteigen.
Wenn ich mir das nach Ihren Worten noch einmal überlege, scheinen die oben genannten Paketmanager weniger auf die Lebensverlängerung der Sprache C als vielmehr auf die Lebensverlängerung der Programmierer ausgerichtet zu sein, die C verwenden müssen.
Wenn man jetzt in ein neues Haus (C++, Rust ...) umziehen muss und dann Möbel wie OpenGL oder Lua braucht, die im alten Haus standen, musste man sie ohne Paketmanager von Hand herübertragen (linken,
makeausführen, sich die Haare raufen, weil DLL- oderlib-Versionen nicht zusammenpassen, beim Anblick von LNK-Fehlern am liebsten aus dem Fenster springen ...). Jetzt gibt es Paketmanager, also kann man sie sauber wie bei einem professionellen Umzug mitnehmen. Es wurde schon so viel gebaut, dass man manches wohl auch im neuen Haus weiterverwenden muss ...Wenn inzwischen weniger die Vorteile der Sprache selbst zählen als vielmehr der Wert der über all die Jahre angesammelten Erfahrung, dann spürt man wirklich, dass es eine sterbende Sprache ist (...
In vielerlei Hinsicht scheint Rust am stärksten das Image des nächsten C/C++ zu haben. (Unter den einigen Sprachen, die als „next“ gelten, hat es im Vergleich wohl auch am ehesten das Image, relativ am komplexesten zu sein … haha)
Nicht nur dem Image nach, sondern offenbar auch in der Praxis scheint Rust tatsächlich schwierig zu sein.