C++ 2 min de lecture

Pourquoi la sécurité mémoire est-elle si difficile à ajouter au langage C++ ?

Share this article
Pourquoi la sécurité mémoire est-elle si difficile à ajouter au langage C++ ?

Ajouter la sécurité mémoire au C++ est un défi en raison des principes de conception fondamentaux du langage et de son histoire profondément enracinée. Voici les principales raisons pour lesquelles intégrer la sécurité mémoire au C++ est particulièrement difficile :

Les compromis entre performance et sécurité

  • Le C++ est conçu pour offrir des performances maximales et un contrôle fin des ressources système, y compris la mémoire. L’introduction de fonctionnalités de sécurité implique souvent des vérifications à l’exécution, qui peuvent entraîner un surcoût de performance. Cela entre en conflit avec l’éthos du C++ des « abstractions à coût nul », selon lequel aucune fonctionnalité ne devrait entraîner de surcoût si elle n’est pas explicitement utilisée.

La rétrocompatibilité

  • Une immense base de code C++ s’est accumulée au fil des décennies. Garantir que les nouvelles fonctionnalités de sécurité ne cassent pas le code existant est un défi de taille. Les concepteurs du langage doivent s’assurer que l’ajout de la sécurité mémoire ne perturbe pas les systèmes legacy qui reposent fortement sur le comportement actuel du C++.

La gestion manuelle de la mémoire

  • L’une des caractéristiques définissantes du C++ est la gestion manuelle de la mémoire à l’aide de pointeurs, new / deleteet d’allocateurs personnalisés. Introduire des fonctionnalités de sécurité mémoire comme le ramasse-miettes ou la gestion automatisée de la mémoire exigerait des changements significatifs dans la façon dont les programmes C++ sont écrits et pourrait bouleverser les pratiques existantes.

La complexité du langage

  • Le C++ est un langage complexe, dont les nombreuses fonctionnalités interagissent de manière subtile. Ajouter des mécanismes de sécurité mémoire qui fonctionnent de façon cohérente avec toutes ces fonctionnalités — comme RAII (Resource Acquisition Is Initialization), la métaprogrammation par templates et la programmation système bas niveau — ajoute des couches de complexité tant à la conception du langage qu’à son implémentation.

Des cas d’usage variés

  • Le C++ est utilisé dans un large éventail d’applications, du calcul haute performance aux systèmes embarqués et aux applications temps réel. Chaque domaine a ses propres exigences et contraintes. Des fonctionnalités de sécurité mémoire adaptées à un domaine peuvent être inacceptables dans un autre, ce qui rend difficile l’élaboration d’une solution universelle.

Face à ces défis, le comité de normalisation C++ avance avec prudence. Des efforts sont faits pour introduire les fonctionnalités de sécurité progressivement, via des outils ou bibliothèques optionnels, plutôt qu’en les imposant au niveau du langage, permettant aux développeurs d’opter pour des pratiques plus sûres sans sacrifier la flexibilité et les performances qui font la réputation du C++.

Heureusement, le comité de normalisation C++ (WG21) se concentre de plus en plus sur la sécurité mémoire, avec des travaux en cours pour intégrer des vérifications de sécurité à la compilation sans sacrifier les performances. Cette évolution devrait rendre le C++ plus sûr par défaut, répondant aux préoccupations de longue date sur les problèmes de gestion mémoire du langage.

Dans cette conférence intéressante, Herb Sutter aborde la sécurité du C++ plus en profondeur.

https://youtu.be/EB7yR-1317k?si=K5XnWn7ifYxSLeqf

Pour comprendre concrètement l’avenir du C++ en matière de sécurité mémoire, vous pouvez suivre la conférence en ligne de Herb Sutter, organisée par MeetingCpp.

Share this article