Top erreurs des développeurs C++ débutants : niveau avancé

Introduction : quand C++ cesse d'être "juste un langage"

Vous avez déjà écrit une dizaine de programmes console, appris à utiliser std::vector et même compris les templates. Mais C++ est un langage qui ne pardonne jamais une approche superficielle. Le développeur débutant passe au niveau supérieur exactement au moment où il rencontre un comportement indéfini (UB) et commence à comprendre que le compilateur n'est pas un ami bienveillant, mais un partenaire strict.

Dans cet article, nous n'aborderons pas les erreurs banales comme un ; oublié ou une confusion entre = et ==. Nous parlerons des pièges qui guettent ceux qui connaissent déjà la syntaxe, mais n'ont pas encore maîtrisé la philosophie du langage. Ces erreurs sont la cause de 90 % des bugs difficiles à détecter dans le code industriel.

1. Ignorer la Rule of Five et la Rule of Zero

Problème : fonctions membres spéciales générées implicitement

De nombreux développeurs venant de Java ou Python pensent que le compilateur va "tout faire joliment" pour la copie et le déplacement des objets. C'est une idée fausse dangereuse.

Considérons une classe avec une ressource dynamique :

class Buffer {public:    Buffer(size_t size) : data(new char[size]), size(size) {}    ~Buffer() { delete[] data; }        // Tout va bien ? Non ! Pas de constructeur de copie ni d'opérateur d'affectation !private:    char* data;    size_t size;};

void process() {    Buffer a(100);    Buffer b = a;  // Copie superficielle ! Deux pointeurs vers la même mémoire.} // Double libération — UB !

La règle Rule of Five stipule : si vous définissez au moins un des cinq méthodes spéciales (destructeur, constructeur de copie, opérateur d'affectation par copie, constructeur de déplacement, opérateur d'affectation par déplacement), vous devez les définir toutes.

Solution : Utilisez std::unique_ptr ou std::vector pour gérer les ressources. C'est l'approche Rule of Zero : si votre classe ne gère pas directement les ressources, le compilateur générera lui-même les fonctions spéciales correctes.

class Buffer {public:    Buffer(size_t size) : data(std::make_unique<char[]>(size)), size(size) {}    // Rule of Zero — le destructeur, la copie et le déplacement fonctionnent correctement !private:    std::unique_ptr<char[]> data;    size_t size;};

2. Mauvaise utilisation de la sémantique de déplacement

Problème : move ne rend pas l'objet "vide" automatiquement

L'une des erreurs les plus sournoises est de croire qu'après std::move, l'objet source devient "sûr" à utiliser. En réalité, std::move n'est qu'une conversion en référence rvalue. L'état de l'objet déplacé dépend de l'implémentation.

std::string a = "Hello, World!";std::string b = std::move(a);std::cout << a;  // Techniquement — UB ? Non, mais le contenu de a est indéfini !// Peut être une chaîne vide, ou bien "Hello, World!"

La norme garantit seulement que l'objet déplacé se trouve dans un état correct mais indéfini. Vous pouvez appeler a.clear() ou a = "new value", mais vous ne devez pas vous fier à son contenu.

Conseil : Après un déplacement, soit réinitialisez l'objet dans un état connu, soit cessez de l'utiliser. Pour les types personnalisés, documentez toujours les post-conditions du constructeur de déplacement.

3. Fuites mémoire via les pointeurs bruts et les exceptions

Problème : les exceptions "brisent" la chaîne de libération des ressources

Même les développeurs expérimentés écrivent parfois du code avec une gestion manuelle de la mémoire :

void process() {    int* ptr1 = new int(42);    int* ptr2 = new int(100);        // Si une exception est levée ici — fuite de ptr1 !    dangerous_function();        delete ptr2;    delete ptr1;}

En C++, il n'y a pas de finally