Ce que le langage C devrait manifestement faire

• Améliorations évidentes de C

  • Norme C23 : le langage C évolue régulièrement et en est désormais à C23. Cependant, certains problèmes restent encore non résolus.
  • Efforts de la communauté Dlang : l’intégration d’un compilateur C (ImportC) dans le compilateur du langage D offre l’occasion de résoudre ces problèmes.

• Évaluation des expressions constantes

  • Problème : C peut calculer des expressions simples à la compilation, mais ne peut pas exécuter de fonctions.
  • Solution d’ImportC : ImportC permet l’exécution de fonctions à la compilation, ce qui dépasse cette limitation.

• Tests unitaires à la compilation

  • Problème en C : dans du code C, les tests unitaires nécessitent une cible de build distincte, ce qui est contraignant.
  • Avantage d’ImportC : ImportC facilite l’exécution de tests unitaires grâce à l’évaluation de fonctions à la compilation.

• Références anticipées dans les déclarations

  • Limitation de C : C est sensible à l’ordre des déclarations et n’autorise pas les références anticipées.
  • Avantage d’ImportC : ImportC n’est pas contraint par l’ordre des déclarations et autorise les déclarations globales dans n’importe quel ordre.

• Importation de déclarations

  • Problème de l’approche existante : il est fastidieux de devoir écrire un fichier .h pour chaque module externe.
  • Solution d’ImportC : ImportC peut importer des déclarations sans fichier .h, ce qui est plus efficace.

• Références

  • Documentation d’ImportC : fournit des informations détaillées sur ImportC.
  • Documentation du langage D : fournit des informations complémentaires sur le langage D.

[GN⁺]

Avis Hacker News

• Les fichiers d’en-tête du langage C sont utiles car ils permettent de distinguer clairement ce qui est public de ce qui ne l’est pas, ainsi que l’interface de l’implémentation. Les fichiers .h permettent de comprendre facilement comment utiliser une bibliothèque

  • La documentation est concentrée dans les fichiers .h, ce qui les rend différents des fichiers .c
  • On peut aussi mettre la documentation dans les fichiers .c, mais cela rend l’interface moins agréable à lire

• Certains estiment qu’il devrait être possible d’exécuter des fonctions à la compilation en C, mais les fonctions dont le temps d’exécution est long peuvent poser problème

  • La fonction busybeaver est citée en exemple

• On s’interroge sur des solutions à des problèmes comme l’évaluation des expressions constantes, les tests unitaires à la compilation, les références anticipées de déclarations et l’import de déclarations

  • Évaluation des expressions constantes : c’est simple si l’on travaille à l’intérieur d’une unité de traduction, mais cela impose de dupliquer du code
  • Tests unitaires à la compilation : c’est possible avec des macros, mais l’ajout du premier point faciliterait les choses
  • Références anticipées de déclarations : cela obligerait le compilateur à effectuer deux passes, avec un impact possible sur les performances
  • Import de déclarations : cela pourrait casser certaines méthodes d’implémentation des templates en C

• Il est possible d’écrire des tests unitaires pour du code C avec un bon système de build et un peu de boilerplate

  • Le code de test de la bibliothèque npy est cité en exemple

• Quand l’évaluation des expressions constantes devient complexe, la vitesse du compilateur peut chuter, et une VM peut devenir nécessaire

  • Selon un avis, il aurait mieux valu aller vers l’import de modules sous forme de symboles plutôt que vers la définition de C++20

• Les tests unitaires à la compilation retirent du contrôle aux développeurs et imposent des étapes inutiles pour terminer le travail

  • Les tests d’échec de build conviennent bien au build final, mais pas aux builds intermédiaires

• Discussion sur le fait de savoir s’il est préférable de définir les fonctions de manière « descendante »

  • Même dans des langages comme Python, la définition descendante est courante
  • Question sur le fait de savoir si cette approche est mieux adaptée à certains types de code

• Fonctionnalités qu’on aimerait voir ajoutées au langage C

  • Prise en charge d’un type slice qui encode un pointeur et une longueur
  • API réentrantes et thread-safe
  • Standardisation d’une fonctionnalité comme defer de Go et Zig
  • Prise en charge portable d’Unicode et de l’UTF-8

• La simplicité de l’implémentation de C est un avantage, et élargir fortement son périmètre n’est pas une bonne idée

  • Il pourrait exister, comme pour Scheme, une spécification « petite » et une spécification « grande »

• Pourquoi il vaut mieux définir les fonctions de haut en bas

  • Cela ressemble à la manière d’écrire du code à l’intérieur d’une fonction
  • La position des fonctions dans un module est claire
  • Cela permet d’identifier clairement les dépendances circulaires
  • Les dépendances circulaires complexifient la base de code et rendent les modules plus difficiles à comprendre
  • OCaml n’autorise pas les dépendances circulaires entre fonctions