CppCon 2016 : Herb Sutter revisite les règles à suivre pour écrire un code sans fuites dans C++ par défaut

**Coriolan** · 30/09/2016, 07h06

CppCon 2016 : Herb Sutter revisite les règles à suivre pour écrire un code sans fuites dans C++
Dans des situations de complexité croissante

Une gestion sûre de la durée de vie des objets implique d'écrire du code qui, par construction, garantit d’éliminer deux choses :

l’usage d'un pointeur nul ou ne pointant pas sur un objet valide (par pointeur, on entend tout ce qui ressemble à des pointeurs, comme les références, les itérateurs, les vues (view) et les intervalles (range)) ;
les fuites de mémoire (même dans le pour cent de cas rares de cycles de propriétés ou de structures de données concurrentes sans verrouillage (lock-free)).

L’année dernière, Herb Sutter, qui est architecte logiciel chez Microsoft et dirige le comité de normalisation ISO C++, s’est penché sur le premier problème, les pointeurs nuls ou invalides, qu’il juge plus difficile et généralement plus sérieux. Durant sa conférence « Writing Good C++14… By Default », il a passé en revue une nouvelle manière d'utiliser des règles d’analyse statique pour détecter l’usage de pointeurs nuls ou invalides en C++. Le travail sur ce sujet a continué tout au long de l'année et des règles formalisées mettant en œuvre cette approche sont en cours d'écriture.

Cette année, sa présentation se focalise sur le deuxième problème, les fuites de mémoire. Sa présentation commence par présenter un ensemble de règles très simples : 5 minutes suffisent à les apprendre. Cette poignée de règles peut être enseignée sans distinction à des programmeurs de tout niveau et permet d'obtenir, par construction, un code propre et sans fuite de mémoire. Comme il reste 85 minutes de présentation disponibles, il en profite pour explorer une série d’exemples de code, avec laquelle il montre « pourquoi et comment » appliquer ces règles dans des situations de complexité croissante, ces situations ciblant des programmes et programmeurs de plus en plus avancés et "rusés" (ce qui n'est pas toujours un compliment pour un développeur).

Sutter va répondre à des questions comme : comment peut-on représenter les types Pimpl ? Comment peut-on représenter une arborescence — quels seront les types des pointeurs enfant et pointeurs parents, quand doivent-ils être uniques ou partagés ? Comment devrait-on faire face aux cycles « intra-module » ou « internes », où l'on contrôle tous les objets participant au cycle, par exemple les nœuds d'un graphe ? Que faire pour les cycles « externes », quand on ne connait pas en avance tous les objets qui pourraient être dans le cycle, par exemple quand on combine des bibliothèques écrites par différentes personnes d’une façon qui peut ou non respecter les différentes couches d'une architecture (les fonctions de rappel [callbacks] sont, par exemple, réputées pour ne pas respecter ces couches) ?

Les réponses se concentrent d'abord sur des cas où les conseils sont connus et reconnus, puis Sutter passe à d’autres approches plus expérimentales afin de tenter de prendre en compte le pourcent de cas pour lesquels unique_ptr, shared_ptr et weak_ptr ne répondent pas totalement aux problèmes.