FAQ C++Consultez toutes les FAQ

Parfois, on est confronté à des problèmes très étranges et apparemment sortis de nul part :

• plantage Access Violation, core dump, null pointer ;
• plantage ou erreur lors d'un appel à new ou à delete DAMAGE : After Normal Block (#47), Heap block 3228a8 modified, Invalid Address specified to RtlFreeHeap ;
• variables qui changent de valeur sans qu'on y ait touché ;
• erreur lors d'une affectation, d'un passage de paramètres, d'une copie ;
• contenu inattendu dans des tableaux ;
  

• les constructeurs par recopie de vos objets qui allouent des ressources ;
• qu'il n'y a pas de débordement mémoire quelque part, en particulier à proximité de l'objet victimes de comportements étranges ;
• que vos pointeurs sont correctement initialisés, et qu'ils ne pointent pas vers des données qui ont été libérées / détruites par la suite.
  

• vous utilisez delete [] non pas delete pour libérer des tableaux alloués avec new []
• vous utilisez delete pour libérer une allocation faite avec new, et free() pour malloc() ne pas mélanger les deux !)
• que vous n'avez pas désalloué une ressource deux fois
• que le pointeur retourné par new n'a pas été modifié ou altéré avant son passage à delete

Sous Windows, quand on lance un programme console depuis certains IDE (tel que Dev C++), sa console n'est visible que durant son exécution. Si ce dernier ne fait qu'afficher un message, elle va donc disparaître immédiatement sans que l'on puisse lire quoique ce soit. Une solution simple consiste donc à attendre que l'utilisateur appuie sur la touche entrée avant de se terminer, comme dans l'exemple suivant :

1
2
3
4
5
6
7
8
9
10
11
12
#include <iostream>  
#include <limits>  
  
using namespace std; 
  
int main() 
{ 
    cout << "Hello World !\n"; 
  
    // attendre avant de quitter 
    cin.ignore( numeric_limits<streamsize>::max(), '\n' ); 
}

La raison la plus probable est l'absence de la directive using namespace std;. Cette directive était optionnelle avec gcc 2.x (ceci était un défaut de conformité au standard). Il faut maintenant, avec gcc 3.x qui est conforme au standard, la mettre dans chaque fichier source, après le bloc des #include. Le programme ainsi modifié compilera aussi bien avec gcc 2.x que gcc 3.x.

En ajoutant un fichier lib à la ligne de commande avec devcpp vous aurez l'erreur suivante :

Si en compilant un programme C/C++ sous Windows vous obtenez un message d'erreur du type

L'implémentation de la STL livrée avec Visual C++ 6 possède divers bugs. Il est vivement conseillé de procéder à sa mise à jour à partir du site de Dinkumware qui est l'auteur de cette implémentation. Pour cela, lire la page Fixes for Library Bugs in VC++ V5.0/V6.0>.

Vous trouverez des solutions à divers problèmes spécifiques à Visual C++ dans la FAQ Visual C++.

Pas de panique, il se peut que ce soit normal. Si vous utilisez un outil de détection de fuites mémoires (par exemple valgrind) sur ce programme, avec certains compilateurs (par exemple gcc) vous verrez un rapport indiquant de la mémoire non libérée :

1
2
3
4
5
6
7
8
9
10
11
#include <string> 
#include <iostream> 
  
using namespace std; 
  
int main() 
{ 
    string s("hello world"); 
    cout << s << endl; 
    return EXIT_SUCCESS; 
}

1
2
3
4
5
LEAK SUMMARY: 
    definitely lost : 0 bytes in 0 blocks. 
    possibly lost :   0 bytes in 0 blocks. 
    still reachable: 960 bytes in 1 blocks. 
         suppressed: 0 bytes in 0 blocks.

• En définissant la macro __USE_MALLOC (gcc versions 2.91, 2.95, 3.0 et 3.1)
• En définissant la variable d'environnement GLIBCPP_FORCE_NEW (gcc versions 3.2.2 et supérieures)
• Si avez le goût du risque, vous pouvez également réécrire vos propres allocateurs