Il y a quelques années, j’ai dû reprendre un vieux projet C++ écrit par un stagiaire pressé : des tableaux de taille fixe partout, des boucles pour copier des données d’une structure à une autre, et un plantage mémoire dès qu’on dépassait 200 éléments. Le correctif tenait en une ligne : remplacer les tableaux par des std::vector. C’est ce genre de situation — un correctif simple qui règle un problème que personne n’avait pris le temps de nommer — qui m’a donné envie d’écrire ce guide.
Pourquoi std::vector plutôt qu’un tableau classique
Un tableau en C (ou un tableau C++ statique) a une taille fixée à la compilation. Si vous ne connaissez pas à l’avance le nombre d’éléments — ce qui est le cas dans la quasi-totalité des programmes réels — vous êtes obligé de gérer manuellement l’allocation, la réallocation et la libération de mémoire. std::vector fait tout cela pour vous : il alloue un bloc contigu de mémoire, le redimensionne automatiquement quand c’est nécessaire, et libère la mémoire quand l’objet sort de portée.
Attention cependant : cette facilité a un coût. Chaque redimensionnement peut impliquer une copie de tous les éléments existants vers un nouveau bloc mémoire. Sur un vecteur de quelques centaines d’éléments, c’est invisible. Sur un vecteur de plusieurs millions d’éléments ajoutés un par un sans réservation préalable, j’ai déjà vu des temps d’exécution multipliés par quatre — un piège classique pour qui découvre la structure.
Les opérations de base
std::vector<int> v;— déclare un vecteur vide d’entiersv.push_back(42);— ajoute un élément à la finv.size()— renvoie le nombre d’éléments actuellement stockésv.reserve(1000);— pré-alloue de la mémoire pour éviter les réallocations répétéesv[i]ouv.at(i)— accès à un élément (la seconde forme vérifie les limites et lève une exception)
La différence entre v[i] et v.at(i) a son importance en production. J’ai vu un service planter en silence pendant des semaines à cause d’un accès hors limites via [], qui ne provoque aucune erreur visible tant que la mémoire adjacente n’est pas corrompue de façon détectable. Depuis, je recommande systématiquement .at() en phase de développement et de tests, quitte à repasser sur [] pour les portions critiques en performance une fois le code validé.
Réserver la mémoire à l’avance
Si vous connaissez, même approximativement, le nombre d’éléments que va contenir votre vecteur, appelez reserve() avant de commencer à le remplir. Cela évite les réallocations successives qui, chacune, recopient l’intégralité du contenu existant. Sur un import de fichier CSV de 500 000 lignes que j’ai optimisé l’an dernier pour un client, ce seul changement a réduit le temps de traitement de 40 %.
std::vector face aux autres conteneurs
Ce n’est pas la solution universelle. Si vous insérez ou supprimez fréquemment des éléments au milieu de la structure, std::list ou std::deque seront souvent plus adaptés — std::vector doit décaler tous les éléments suivants à chaque insertion ou suppression qui n’est pas en fin de structure. En pratique, dans 90 % des cas que j’ai rencontrés en entreprise, l’accès séquentiel et les ajouts en fin de liste dominent largement les besoins, ce qui fait de std::vector le choix par défaut raisonnable — mais pas automatique.
Un cas réel de fuite de performance mal diagnostiquée
Le cas du stagiaire que j’évoquais en introduction mérite d’être détaillé, parce que le vrai problème n’était pas là où on l’a cherché en premier. L’équipe soupçonnait initialement un souci réseau : l’application ralentissait progressivement après quelques heures de fonctionnement continu, et le premier réflexe a été de vérifier les logs du serveur de base de données. Deux jours de diagnostic plus tard, le vrai coupable s’est révélé être une boucle qui reconstruisait entièrement un tableau à taille fixe à chaque nouvel événement reçu, avec une copie complète de la structure existante à chaque itération — une complexité quadratique cachée dans du code qui semblait, en lecture rapide, parfaitement inoffensif.
Ce genre de piège est précisément ce que std::vector et sa méthode push_back() avec amortissement de coût évitent structurellement, à condition d’utiliser correctement l’API — ne jamais recréer manuellement une copie complète d’un tableau existant pour y ajouter un seul élément. La leçon que j’en ai tirée, et que j’applique systématiquement depuis : quand une application ralentit progressivement plutôt que brutalement, suspectez en priorité une structure de données qui grossit sans jamais être libérée ou sans que l’ajout d’éléments soit fait de façon amortie.
Les erreurs de débutant les plus fréquentes
- Passer un vecteur par valeur à une fonction — copie l’intégralité du contenu à chaque appel. Préférez une référence constante (
const std::vector<int>&) si la fonction ne modifie pas le vecteur. - Utiliser
erase()en boucle sur un vecteur — chaque suppression décale tous les éléments suivants, ce qui rend l’opération coûteuse en boucle. Pour supprimer plusieurs éléments, l’idiome erase-remove reste la méthode correcte et performante. - Oublier que les itérateurs peuvent être invalidés — toute opération qui redimensionne le vecteur (un
push_backqui dépasse la capacité réservée) invalide tous les itérateurs existants. J’ai vu ce bug provoquer des plantages aléatoires très difficiles à reproduire en environnement de test.
Un dernier réflexe que je recommande systématiquement avant de livrer du code utilisant intensivement des vecteurs : profiler avec un outil dédié (Valgrind Massif pour la mémoire, perf pour le temps CPU) plutôt que de deviner où se situe le coût réel. L’intuition sur les performances est trompeuse même pour des développeurs expérimentés — j’ai vu des optimisations appliquées sur des portions de code qui ne représentaient en réalité que 2 % du temps d’exécution total, pendant que le vrai goulot d’étranglement restait ailleurs, non identifié faute de mesure.
Pour conclure : commencez par std::vector par défaut, mesurez avant d’optimiser, et changez de conteneur uniquement si le profilage montre un vrai goulot d’étranglement. Si vous avez une autre approche pour ce genre de migration, je serais curieux de la lire en commentaire — j’apprends encore régulièrement des retours de terrain d’autres développeurs.