Combattre les fuites de mémoire et les erreurs C++11

Le langage C++ nous laisse attribuer et libérer la mémoire par nous-mêmes. Chaque variable possède sa propre zone dans la mémoire. Cette mémoire est libérée quand l'application sort de sa portée de validité qui est limitée par les caractères { et }. Dans ce cas, il n'y a aucun risque de voir la perte de mémoire augmenter, car la mémoire est libérée automatiquement. Cependant, C++ nous autorise également à allouer la mémoire de façon dynamique. Cela signifie que vous pouvez recevoir la quantité de mémoire dont vous avez besoin, et celle-ci ne sera pas libérée automatiquement par le système. Cela veut dire que vous êtes obligé de libérer cette zone lorsque vous n'en avez plus besoin. Si vous oubliez ce point, vous provoquerez des fuites mémoire.

Chaque fuite de mémoire se traduit par un besoin supérieur en mémoire. En fonction de la quantité de mémoire perdue, les fuites sont plus ou moins dangereuses. Vous devez comprendre qu'une fonction qui provoque des fuites de mémoire peut provoquer une perte d'une énorme quantité de mémoire lorsqu'elle est appelée des centaines ou des milliers de fois pendant l'exécution. Bien sûr, à la fin du programme, le ramasse-miettes s'occupera de nettoyer cette mémoire non libérée. Alors, pourquoi nous inquiétons-nous de cette mémoire non libérée ? Dans le cas d'applications utilisées quotidiennement, les petites fuites mémoire sont indécelables. La situation s'aggrave lorsque des programmes fonctionnent sans relâche pendant des semaines ou même des mois (par exemple, des serveurs HTTP, DNS, e-mail, bases de données, etc.). Si de telles applications ne libèrent pas les zones inutilisées en mémoire, elles provoquent un usage plus grand de la mémoire. Cela peut affecter le système qui tuera une application pouvant avoir une fonction très importante.

La situation est encore plus grave dans le cas d'applications utilisant beaucoup de ressources. Un logiciel de rendu 3D est un bon exemple. Un processus de création de scènes 3D requiert beaucoup de mémoire vive. Si ce logiciel ne se charge pas correctement de la libération mémoire non utilisée, nous pouvons perdre beaucoup d'heures de calcul.

Pour détecter les fuites de mémoire (et les erreurs), nous pouvons utiliser une application dédiée comme valgrind. Ce logiciel est disponible pour les systèmes d'exploitation avec un noyau Linux et les systèmes compatibles UNIX. Pour tester notre programme avec valgrind, nous avons besoin de son exécutable.

En premier lieu, vous devez savoir que valgrind teste le programme pendant son exécution. Il ne s'intéresse ni au code source ni au code binaire. Il suffit d'utiliser l'application. Ce qui pourrait poser problème, car les fuites de mémoire ne seront pas détectées si la fonction qui les génère reste inutilisée pendant l'exécution du programme. Le moyen le plus facile d'éviter ce problème est d'utiliser toutes les fonctions dans une simple application de test. Si votre code est plus sophistiqué et comporte de nombreux modules, écrivez de plus petites applications de test - une ou deux pour chaque module.

Si vous écrivez des tests unitaires et, pour cela, vous utilisez une bonne bibliothèque qui ne génère ni erreurs ni fuites de mémoire, vous pouvez utiliser ces tests avec valgrind. L'exécuter ressemble à ça :

valgrind [options de valgrind] /chemin/vers/application paramètres de l'application

Pour connaître les options de valgrind, écrivez :

valgrind --help

Si vous voulez obtenir des informations détaillées à propos des fuites de mémoire, utilisez l'option :

--leak-check=full

V-A. Exemple n° 1▲

#include <iostream>

int main (int argc, char** argv)
{
  int *x = new int [1000];
  {
    int y ;
    int *z = new int [1000];
  } // le pointeur z et la variable y sont enlevés de la mémoire
  delete [] x; // libère la mémoire allouée à la ligne 4
  
  return 0;
}

V-B. Exemple n° 2▲

#include <iostream>
#include <stdexcept>

int main(int argc, char** argv)
{
  try {
    int *x = new int[1000];
    throw std::logic_error("logic_error");
    delete [] x;
  } catch (std::logic_error &e)
  {
    std::cerr << "une exception a été levée: " << e.what() << "\n";
    return  1;
  }
}

V-C. Exemple n° 3▲

#include <iostream>
#include <stdexcept>
 
class Database
{
private:
  int size;
  int* data;
 
public:
  Database(int n) :
    size(n),
    data(new int[n])
  {}
 
  int get(int i)
  {
    if (i < 0 || i >= size)
    {
      throw std::out_of_range("Database");
    }
 
    return data[i];
  }
   
  ~Database()
  {
    delete [] data;
  }
};
 
int main(int argc, char** argv)
{
  try {
    Database *db = new Database(10);
    db->get(10);
    delete db;
  } catch (std::out_of_range &e)
  {
    std::cerr << "out_of_range in " << e.what() << "\n";
    return 1;
  }
  return 0;
}

Une autre erreur possible est d'utiliser de la mémoire qui ne nous appartient pas. Cette erreur est souvent faite par des programmeurs non expérimentés qui viennent de débuter le codage et ne sont pas au fait que l'index maximum d'un tableau de 100 éléments n'est pas 100, mais 99. Cette erreur peut être détectée pendant l'exécution, mais ce n'est pas une règle. Cela ne veut pas dire que tout est OK quand nous utilisons mal notre propre mémoire. Jetons un coup d'½il aux exemples.

VI-A. Exemple n° 1▲

int main(int argc, char** argv)
{
  int tab[100];
  tab[100] = 10;
  return 0;
}

VI-B. Exemple n° 2▲

#include <iostream>
 
int main(int argc, char** argv)
{
  int a[100];
  int b[100];
  b[0] = 1;
  std::cout << "b[0] = " << b[0] << "\n";
  a[100] = 2;
  std::cout << "b[0] = " << b[0] << "\n";
  std::cout << "Comparaison des adresses de a[100] et b[0]:\n";
  int* p1 = &a[100];
  int* p2 = &b[0];
  if (p1 == p2)
  {
    std::cout << "Adresses identiques! (" << reinterpret_cast<void*>(p1) << ")\n";
  } else
  {
    std::cout << "Adresses différentes!\n";
  }
  return 0;
}

VI-C. Exemple n° 3▲

int main(int argc, char** argv)
{
  int* p = new int[10];
  p[10] = 10;
  int a = p[10];
  return 0;
}

VI-D. Exemple n° 4▲

int main(int argc, char** argv)
{
  int* p = new int[10];
  delete [] p;
  p[2] = 10;
  return 0;
}

Combien de fois avez-vous entendu : « affectez la valeur de la variable après sa création ! » ? La plupart des livres sur la programmation mentionnent cette règle. Cela sera moins nocif lorsque vous ratez un examen sur les algorithmes parce que vous avez écrit int sum; au lieu de int sum = 0;. Cela serait pire de perdre de nombreuses heures en raison d'une mémoire non initialisée. Quand nous utilisons un pointeur non initialisé qui se trouve quelque part, il est hautement probable que nous utiliserons un autre processus mémoire et notre programme sera déchargé par le système d'exploitation. Les variables normales, initialisées par nous-mêmes, appartiennent certainement à notre processus alors qu'un défaut d'initialisation sera plus énervant.

int main(int argc, char** argv)
{
  int x;
  if (x == 10)
  {
    x = 20;
  }
  return 0;
}

Heureusement, valgrind nous informe de l'utilisation d'une variable ou d'un pointeur non initialisé :

==8777== Conditional jump or move depends on uninitialised value(s)
==8777== at 0x4005AD: main (example7.cpp:4)

Se prémunir des erreurs mémoire dans des programmes C++ est possible sans outils spécialisés. La présence des destructeurs, souvent sous-estimés des programmeurs, est très utile. Quand vous créez un objet qui alloue lui-même sa mémoire, son destructeur devrait prendre soin de la libérer. Voici quelques bonnes pratiques qui, utilisées, devraient vous éviter les fuites et les erreurs :

1. Lorsque vous utilisez l'opérateur new dans un constructeur, utilisez delete dans le destructeur ;
2. Lorsque vous utilisez un pointeur local dans une fonction membre (qui n'est pas un attribut de la classe courante), il est hautement probable qu'une variable locale soit suffisante ;
3. Si vous êtes sûr que dans la situation précédente (2) une variable locale n'est pas suffisante, considérez l'utilisation de l'opérateur delete avant de quitter cette fonction ;
4. Si vous devez allouer dynamiquement de la mémoire dans une fonction et ne pouvez pas la libérer avant de quitter la portée, sauvez son adresse dans un pointeur externe qui est accessible hors de la fonction.

Nous avons des conteneurs de bibliothèques standard qui libèrent la mémoire automatiquement. Les utiliser habilement vous évitera les problèmes de gestion mémoire. Il peut être intéressant d'utiliser la fonction std::vector::at à la place de l'opérateur []. Cette fonction teste si un index est à l'intérieur de la plage. Dans le cas où l'index est trop petit ou trop grand, elle lève une exception.

Avec le standard C++11, nous avons aussi les pointeurs intelligents qui libèrent la mémoire qu'ils pointent automatiquement. Je peux décrire leur fonctionnement avec deux règles simples :

• std::shared_ptr peut être copié. Lorsque la dernière copie est détruite, la mémoire qu'il pointait est libérée ;
• std::unique_ptr ne peut pas être copié (il est unique). Lorsqu'il est détruit, la mémoire qu'il pointait est également libérée.

Il est très important pour être cohérent d'utiliser des pointeurs intelligents pour une seule zone mémoire. Utiliser des pointeurs standard avec des pointeurs intelligents (partagés ou uniques) peut provoquer de sérieux problèmes (par exemple une double libération de mémoire). Vous devez utiliser les fonctions std::make_unique et std::make_shared pour créer des pointeurs intelligents. Vous ne devez pas les utiliser pour pointer sur de la mémoire allouée sur la pile ou sur de la mémoire libérée manuellement (par l'opérateur delete).

Suivre les règles énoncées ci-dessus devrait vous aider à éliminer les problèmes de mémoire. Les différentes facilités de C++11 et C++14 font que nous n'avons pas de bonnes excuses pour les fuites de mémoire. Je vous encourage à apprendre les nouveaux outils standard du C++. Les utiliser raisonnablement devrait rendre votre code meilleur.

Cet article est une traduction autorisée de l'article de paru sur le site de Kacper Kołodziej.

Merci aussi à ClaudeLELOUP pour sa relecture orthographique.