Offensichtliche Dinge, die die Programmiersprache C tun sollte

 (digitalmars.com)
2 Punkte von GN⁺ 2025-01-13 | 1 Kommentare | Auf WhatsApp teilen

  • Offensichtliche Verbesserungen an C

    • C23-Standard: Die Programmiersprache C wird regelmäßig weiterentwickelt und hat inzwischen C23 erreicht. Dennoch gibt es weiterhin ungelöste Probleme.
    • Bemühungen der Dlang-Community: Durch die Einbettung eines C-Compilers (ImportC) in den Compiler der Programmiersprache D ergibt sich die Möglichkeit, diese Probleme zu lösen.

  • Auswertung konstanter Ausdrücke

    • Problem: C kann einfache Ausdrücke zur Compile-Zeit berechnen, aber keine Funktionen ausführen.
    • Lösung von ImportC: ImportC erlaubt die Ausführung von Funktionen zur Compile-Zeit und überwindet damit diese Einschränkung.

  • Unit-Tests zur Compile-Zeit

    • Problem in C: Unit-Tests in C-Code erfordern ein separates Build-Target und sind daher umständlich.
    • Vorteil von ImportC: ImportC ermöglicht durch Funktionsauswertung zur Compile-Zeit die einfache Ausführung von Unit-Tests.

  • Vorwärtsreferenzen bei Deklarationen

    • Einschränkung von C: C ist empfindlich gegenüber der Reihenfolge von Deklarationen und erlaubt keine Vorwärtsreferenzen.
    • Vorteil von ImportC: ImportC ist nicht an die Reihenfolge von Deklarationen gebunden und erlaubt globale Deklarationen in beliebiger Reihenfolge.

  • Deklarationen importieren

    • Problem des bisherigen Ansatzes: Für jedes externe Modul müssen umständlich .h-Dateien geschrieben werden.
    • Lösung von ImportC: ImportC kann Deklarationen auch ohne .h-Dateien importieren und ist dadurch effizienter.

  • Referenzmaterial

    • ImportC-Dokumentation: Bietet detaillierte Informationen zu ImportC.
    • D-Sprachdokumentation: Bietet weitere Informationen zur Programmiersprache D.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-01-13
Hacker-News-Kommentare

  • Bei C ist es gut, dass Header-Dateien klar zwischen öffentlich und nicht öffentlich sowie zwischen Interface und Implementierung unterscheiden können. Über .h-Dateien lässt sich leicht erkennen, wie eine Bibliothek verwendet wird.

    • Die Dokumentation konzentriert sich auf die .h-Dateien und wirkt daher anders als in den .c-Dateien.
    • Man kann die Dokumentation auch in .c-Dateien unterbringen, aber das macht das Interface schwerer lesbar.

  • Es gibt die Meinung, dass C die Ausführung von Funktionen zur Compile-Zeit ermöglichen sollte, aber bei Funktionen mit langer Laufzeit könnte das problematisch sein.

    • Ein Beispiel dafür ist die Funktion busybeaver.

  • Es wird gefragt, wie Probleme wie die Auswertung konstanter Ausdrücke, Unit-Tests zur Compile-Zeit, Vorwärtsreferenzen bei Deklarationen und das Importieren von Deklarationen gelöst werden sollen.

    • Auswertung konstanter Ausdrücke: Innerhalb einer Translation Unit ist das einfach, erfordert aber Code-Duplizierung.
    • Unit-Tests zur Compile-Zeit: Mit Makros ist das möglich, aber wenn der erste Punkt hinzukommt, wird es einfacher.
    • Vorwärtsreferenzen bei Deklarationen: Der Compiler müsste zwei Durchläufe machen, was die Performance beeinträchtigen könnte.
    • Deklarationen importieren: Dadurch könnten Methoden zur Implementierung von Templates in C kaputtgehen.

  • Unit-Tests für C-Code lassen sich mit einem guten Build-System und etwas Boilerplate schreiben.

    • Als Beispiel wird der Testcode der Bibliothek npy genannt.

  • Wenn die Auswertung konstanter Ausdrücke komplex wird, kann die Compiler-Geschwindigkeit sinken, und eventuell wird eine VM benötigt.

    • Es gibt die Meinung, dass es besser gewesen wäre, Module als Symbole zu importieren statt der Definition aus C++20 zu folgen.

  • Unit-Tests zur Compile-Zeit nehmen Entwicklerinnen und Entwicklern die Kontrolle und verlangen unnötige Verfahren, um die Arbeit abzuschließen.

    • Build-Failure-Tests sind für den finalen Build gut, aber nicht für Zwischen-Builds geeignet.

  • Es wird diskutiert, ob es besser ist, Funktionsdefinitionen „top-down“ zu schreiben.

    • Auch in Sprachen wie Python sind top-down-Definitionen üblich.
    • Es wird gefragt, ob sich top-down-Definitionen besser für bestimmte Arten von Code eignen.

  • Gewünschte zusätzliche Funktionen für C:

    • Unterstützung für Slice-Typen, die Pointer und Länge kodieren.
    • Reentrant- und thread-sichere APIs.
    • Standardisierung einer Funktion wie defer aus Go und Zig.
    • Portable Unterstützung für Unicode und UTF-8.

  • Die einfache Implementierung von C ist ein Vorteil, und eine starke Erweiterung des Umfangs ist keine gute Idee.

    • Wie bei Scheme könnte es eine „kleine“ und eine „große“ Version der Spezifikation geben.

  • Gründe, warum es besser ist, Funktionsdefinitionen von oben nach unten zu schreiben:

    • Es ähnelt der Art und Weise, wie man Code innerhalb einer Funktion schreibt.
    • Die Position von Funktionen innerhalb eines Moduls ist klar.
    • Zyklische Abhängigkeiten lassen sich klar erkennen.
    • Zyklische Abhängigkeiten machen eine Codebasis komplexer und erschweren das Verständnis von Modulen.
    • OCaml erlaubt keine zyklischen Abhängigkeiten zwischen Funktionen.