Mamadou Babaei : « C++ n'a pas besoin d'une nounou comme le vérificateur d'emprunts de Rust »

Faut-il vraiment changer de langage, ou simplement mieux maîtriser les outils existants ?

Alors que Rust s’impose comme le champion de la sécurité mémoire grâce à son système de vérification à la compilation, certains développeurs C++ refusent de se laisser reléguer au rang de programmeurs imprudents. Avec un ton provocateur, le développeur professionnel de jeu Mamadou Babaei défend la capacité du C++ à détecter et corriger les fuites mémoire sans avoir besoin d’un « gardien de mémoire » comme Rust. À travers une démonstration concrète avec _CrtDumpMemoryLeaks, il relance le débat : faut-il vraiment changer de langage, ou simplement mieux maîtriser les outils existants ?

Rust : un langage trop protecteur ?

Rust a été acclamé ces dernières années comme l’un des langages les plus sécurisés pour le développement système. Sa principale innovation ? Le borrow checker (littéralement vérificateur d'emprunts), ce mécanisme de vérification à la compilation qui empêche les erreurs de mémoire comme les accès concurrents non sécurisés ou les use-after-free.

Le vérificateur d'emprunts est une fonctionnalité essentielle du langage Rust et fait partie de ce qui rend Rust Rust. Il vous aide (ou vous oblige) à gérer la propriété. Comme le dit le chapitre 4 de « The Rust Programming Language », « La propriété est la caractéristique la plus unique de Rust, et elle permet à Rust de garantir la sécurité de la mémoire sans avoir besoin d'un collecteur mémoire ».

Le vérificateur d'emprunt est un composant du compilateur Rust dont le rôle est de vérifier à la compilation que l’usage de la mémoire est sûr, sans fuite ni corruption potentielle, sans exécution du programme. Il repose sur trois concepts clés :

• Propriété (ownership) : chaque valeur a un propriétaire unique.
• Emprunts (borrowing) : on peut prêter une valeur de manière mutable ou non mutable, mais pas les deux en même temps.
• Durée de vie (lifetimes) : chaque référence a une durée de vie clairement définie et vérifiée.

Le borrow checker interdit à la compilation :

• Les accès concurrents à une même valeur mutable (race conditions évitées).
• Les références à des valeurs qui ont été libérées (dangling pointers).
• La modification de données pendant qu'elles sont empruntées de façon immuable.
• L’utilisation après déplacement (move), pour éviter la double libération.

Mais pour certains développeurs C++, ce système ressemble davantage à une « nounou » : une surprotection qui entrave la liberté de coder rapidement et efficacement. Selon eux, les développeurs expérimentés n’ont pas besoin d’un langage qui leur interdit de faire certaines choses – ils veulent juste des outils qui les aident à le faire mieux, sans être bridés.

Un faux procès fait au C++ ?

Depuis l’essor de Rust dans les milieux de la sécurité et du développement système, une idée reçue semble s’installer : le C++ serait intrinsèquement dangereux. Ses critiques mettent en avant la complexité de sa gestion manuelle de la mémoire, source supposée d’erreurs fréquentes et de vulnérabilités critiques.

Mais ce discours occulte une réalité plus nuancée : le C++ n’est pas dangereux par nature, il est exigeant. Comme le rappelle Babaei, les fuites mémoire et les erreurs d’allocation ne sont pas une fatalité si les développeurs exploitent les outils disponibles dans l’écosystème du langage.

Ainsi, plutôt que de dénigrer le C++ pour son absence de mécanismes de sécurité intégrés à la Rust, il conviendrait de promouvoir les bonnes pratiques de développement, les outils de débogage avancés et les bibliothèques modernes comme RAII, unique_ptr, shared_ptr, ou encore Valgrind.

Dans sa vidéo intitulée « Rust Devs Think We’re Hopeless; Let’s Prove Them Wrong (with C++ Memory Leaks)! », Mamadou Babaei défend avec humour et technicité la capacité des développeurs C++ à gérer efficacement la mémoire, sans recourir aux mécanismes de sécurité stricts de Rust. Il démontre comment détecter les fuites mémoire en C++ en utilisant l'outil _CrtDumpMemoryLeaks fourni par la bibliothèque d'exécution C (CRT) de Microsoft.

Et d'indiquer :

« Lorsque les développeurs Rust pensent à nous, les gens du C++, ils imaginent une lignée maudite - un traumatisme générationnel transmis de malloc à free. Pour eux, chaque ligne de C++ que nous écrivons est comme jouer à la roulette russe - sauf que les six chambres sont chargées de comportements non définis.

« Ils nous regardent comme si nous étions sans espoir. Comme si nous étions à deux doigts d'une thérapie. Mais vous savez quoi ? Nous n'avons pas besoin d'une nounou pour le compilateur. Pas de vérificateur d'emprunts. Pas de durée de vie. Pas de modèles de propriété. Pas de magie noire. Même Valgrind n'est pas nécessaire. Juste des pointeurs bruts, de la détermination brute, et un peu de santé mentale douteuse.

« Dans cette vidéo, je vais donc vous montrer comment traquer les fuites de mémoire comme si vous étiez né avec un pointeur dans une main et un débogueur dans l'autre ».


_CrtDumpMemoryLeaks : Un outil à (re)découvrir

La démonstration de Babaei repose sur un outil méconnu mais redoutablement efficace : la fonction _CrtDumpMemoryLeaks, intégrée à la CRT (C Run-Time Library) de Microsoft. Elle permet, dès la compilation en mode debug, de détecter automatiquement les blocs de mémoire non libérés avant la fin de l’exécution.

En couplant cet outil à des macros de suivi (_CRTDBG_MAP_ALLOC, new redéfini avec traçabilité), il devient possible de cartographier précisément l'origine d'une fuite mémoire. Cette démarche, bien que nécessitant une configuration spécifique, prouve que le C++ n’est pas dépourvu de garde-fous — il demande juste qu’on les active.

Démonstration : détection de fuites mémoire avec _CrtDumpMemoryLeaks

Babaei présente un exemple de programme C++ qui génère intentionnellement une fuite mémoire en allouant de la mémoire sans la libérer. Pour détecter cette fuite, il utilise les fonctions de débogage de la CRT.

Démonstration d'une fuite de mémoire en C++ simple et intentionnelle...