Le langage de programmation C (les problèmes du langage C)
(hut.mearie.org)-
Problèmes de mémoire : aucune aide d’outils comme le GC, l’analyse statique, etc.
-
Comportement indéfini : il a surtout été utilisé dans des environnements bas niveau, avec de fortes exigences d’optimisation, et les comportements indéfinis se sont multipliés pour permettre ces optimisations. Il ne parvient pas à concilier performance bas niveau et portabilité.
-
Inadapté à la programmation à grande échelle : absence de modules et de gestionnaire de paquets. Même des éléments largement utilisés comme
#pragma oncen’ont pas de standard.
7 commentaires
Merci de partager ce bon article. Je laisse toutefois un commentaire, car un petit point m’a intrigué.
C’est l’auteur de l’article (haha...). Le site est actuellement en phase de soft release et j’y publie des articles de manière expérimentale, donc merci de votre compréhension : le contenu peut être modifié en continu. Je fais aussi un suivi direct, mais vous pouvez également m’envoyer vos retours par e-mail, à titre indicatif.
Comme vous l’avez dit, vcpkg semble actuellement être le gestionnaire de paquets le plus prometteur, et Conan est en réalité un projet qui existe depuis assez longtemps déjà (pas très éloigné de la date de rédaction initiale). Mais la caractéristique la plus importante de ces projets est qu’ils sont des systèmes de meta-build qui ne disposent pas eux-mêmes d’un système de build. (Quand on pense que CMake, leur cible principale de prise en charge, est lui-même un système de meta-build, on pourrait même parler d’un système de meta-meta-build...) Il leur est donc difficile de résoudre directement les problèmes qui viennent du système de build lui-même. On voit que vcpkg a été un peu plus réfléchi sur ce point : par exemple, lorsqu’un projet a besoin de versions différentes d’une même dépendance (via des chemins de dépendance différents), il est possible de scinder l’enlistment, mais cela ne reste qu’un moyen de contourner les limites du système de build lui-même. À titre de comparaison, avec Rust et Cargo, dans ce cas, il n’y a aucun problème à construire les deux versions et à les référencer depuis un même crate.
Par ailleurs, vcpkg ne semble pas encore bénéficier dans Visual Studio d’une intégration d’outils au niveau de NuGet (uniquement une intégration MSBuild...), et l’intégration avec les gestionnaires de paquets des distributions Linux/BSD ne semble pas non plus très avancée. C’est d’ailleurs l’un des plus gros problèmes auxquels sont confrontés aujourd’hui les gestionnaires de paquets propres à chaque langage. Des langages récents comme Rust le résolvent au cas par cas, mais un gestionnaire de paquets C/C++ devrait nécessairement viser l’intégration avec les systèmes existants, et sur ce point les progrès restent lents. Ce n’est qu’une fois cet aspect résolu qu’on pourra vraiment dire que des outils de type vcpkg sont devenus d’usage général dans le développement C/C++. Le fait que ce ne soit pas encore le cas est la raison principale pour laquelle j’ai sous-estimé les systèmes de paquets dans l’article. (La prolifération des single-file library mentionnée dans l’article est aussi une preuve indirecte que les systèmes du type vcpkg n’ont pas réussi à être suffisamment convaincants.)
Merci pour cette réponse détaillée. Il est vrai qu’à la base, c’est un système de build, donc contrairement à npm ou à d’autres gestionnaires de paquets, il semble bien qu’il y ait une limite impossible à dépasser. vcpkg semble beaucoup se poser la question des versions en ce moment, mais j’ai l’impression que ce ne sera pas facile à surmonter.
Je me dis aussi que le système de modules de C++20 pourrait être une réponse à ce problème... mais dans ce cas, on dépasse le cadre du langage C (...). On dirait qu’il ne reste plus qu’un chemin semé d’embûches pour le C. Même si une norme C20 était adoptée maintenant, le taux de transition entre versions ne serait sans doute pas aussi élevé qu’en C++..
Merci pour cet avis pertinent.
Voici mon point de vue personnel. Le fait qu’il existe plusieurs gestionnaires de paquets pour C est une bonne chose, mais le problème, c’est qu’ils ne sont pas beaucoup utilisés. Plus précisément, comme l’héritage de C est déjà immense, j’ai l’impression qu’on est peut-être allé trop loin pour résoudre les problèmes mentionnés plus haut. C’est peut-être aussi pour cela qu’il y a de plus en plus de tentatives de migrer vers de nouveaux langages comme Rust.
En vous écoutant, et après y avoir repensé, j’ai l’impression que ces gestionnaires de paquets se concentrent moins sur la prolongation de la vie du langage C que sur la prolongation de la vie des programmeurs qui n’ont pas d’autre choix que d’utiliser le C.
Maintenant qu’il est temps de déménager vers une nouvelle maison (C++, Rust...), quand on a besoin de récupérer des meubles de l’ancienne maison comme OpenGL ou Lua, il fallait auparavant les déplacer à la main sans gestionnaire de paquets (faire le linking, lancer
make, s’arracher les cheveux à cause des versions de DLL ou de lib qui ne correspondent pas... voir des erreurs LNK au point d’avoir envie de sauter par la fenêtre... ). Maintenant, avec les gestionnaires de paquets, on peut les transférer proprement, comme avec un déménagement clé en main. Comme on a déjà construit énormément de choses, il arrivera forcément qu’on doive aussi les réutiliser dans la nouvelle maison...Quand on voit que, désormais, ce ne sont plus vraiment les avantages du langage lui-même qui comptent, mais plutôt le bénéfice de toute l’expérience accumulée jusqu’ici, on sent bien que c’est vraiment un langage en train de mourir (...
À bien des égards, Rust semble avoir l’image la plus marquée du successeur de C/C++. (Parmi les quelques langages considérés comme la relève, il a aussi, relativement, l’image d’être le plus complexe... haha)
Il semble que Rust soit réellement difficile, et pas seulement en image.