FAQ C++Consultez toutes les FAQ

Nombre d'auteurs : 35, nombre de questions : 368, dernière mise à jour : 17 novembre 2018  Ajouter une question

 

Cette FAQ a été réalisée à partir des questions fréquemment posées sur les forums de http://www.developpez.com et de l'expérience personnelle des auteurs.

Je tiens à souligner que cette FAQ ne garantit en aucun cas que les informations qu'elle propose sont correctes ; les auteurs font le maximum, mais l'erreur est humaine. Cette FAQ ne prétend pas non plus être complète. Si vous trouvez une erreur ou si vous souhaitez devenir rédacteur, lisez ceci.

Sur ce, nous vous souhaitons une bonne lecture.


SommaireProblèmes avec les compilateurs (9)
précédent sommaire
 

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 ;

Ces dysfonctionnements ont plusieurs causes possibles, mais ils sont généralement liés à une mauvaise utilisation de la mémoire. La première chose à faire est de compiler votre programme avec les options de débogage activées et de l'exécuter dans un débogueur afin que ce dernier vous emmène précisément à l'endroit où l'erreur est détectée (ce qui ne veut pas dire que c'est là qu'elle a lieu !).
Dans le cas d'un pointeur nul où d'une violation d'accès, il peut s'agir une erreur simple de programmation telle qu'un pointeur non initialisé.
Si vous êtes confronté à une erreur d'apparence plus surnaturelle, vérifiez les points suivants :
  • 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.

Soyez sûrs d'une chose : une variable ne change pas toute seule sans raisons de valeur. Cela est très souvent dû à un débordement qui vient écraser le contenu de votre variable. Vérifiez donc minutieusement l'utilisation que vous faites des pointeurs.
Un autre cas fréquent d'erreur est déclenché par les opérateurs et fonctions de gestion de la mémoire new, delete, malloc(), free(). Il faut savoir que ces derniers, en particulier en mode débogage, effectuent divers tests pour détecter toute mauvaise utilisation ou corruption de la mémoire. Si la vérification échoue, alors une erreur est signalée. Ce n'est donc pas ces opérateurs / fonctions qui sont en cause, mais bien votre code qui les utilise de manière erronée. En particulier, vérifiez bien que :
  • 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

Le message d'erreur vous aide généralement à déceler le problème. Si ce dernier parle de bloc corrompu ou modifié, alors il s'agit d'un débordement mémoire qui a écrasé les données internes ajoutées à proximité de votre allocation par la bibliothèque standard (afin de garder une trace de ce qui a été alloué, de faire des vérification, etc.).

Mis à jour le 18 avril 2005 Aurelien.Regat-Barrel

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 :

Code c++ : Sélectionner tout
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 méthode utilisée pour effectuer cette attente est détaillée dans Comment faire une pause (attendre que l'utilisateur tape une touche) ?.

Mis à jour le 18 avril 2005 Aurelien.Regat-Barrel

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.

Mis à jour le 9 octobre 2003 Anomaly

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

file not recognized C:\Dev-Cpp\lib\glut32.lib File format not recognized
Cela est dû au fait que le port de gcc fourni avec devcpp (MingW) utilise son propre type de fichiers lib portant l'extension .a. Il vous faut donc obtenir une version compatible avec devcpp de la bibliothèque que vous voulez utiliser.
Notez qu'un grand nombre d'entre-elles sont fournies dans le répertoire \lib, comme cela est le cas dans cet exemple avec libglut32.a. Regardez donc dans ce répertoire pour voir si l'équivalent de votre .lib ne s'y trouve pas.

Mis à jour le 22 novembre 2004 Aurelien.Regat-Barrel

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

error LNK2019: symbole externe non résolu _WinMain@16 référencé dans la fonction _WinMainCRTStartup
[Linker error] undefined reference to `WinMain@16'
C'est que vous avez créé un projet Win32 sans console au lieu d'un projet console, ce qui fait que le compilateur s'attend à trouver la fonction d'entrée WinMain() à la place de la fonction standard main(). À partir de Visual C++ 7, vous pouvez modifier les propriétés de votre projet via Propriétés de configuation->Editeur de liens->Système->Sous-système : Console (/SUBSYSTEM:CONSOLE). Pour les versions antérieures, il faut créer un nouveau projet console.

Mis à jour le 22 novembre 2004 Aurelien.Regat-Barrel

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>.

Mis à jour le 22 novembre 2004 Aurelien.Regat-Barrel

Fatal error C1010: unexpected end of file while looking for precompiled header directive
Fatal error C1010: Fin de fichier inattendue lors de la recherche d'une directive d'en-tête précompilé
Cette erreur survient quand votre projet est configuré pour utiliser un fichier d'en-tête précompilé (typiquement stdafx.h). Il vous suffit de désactiver l'utilisation des en-têtes précompilées dans les options C/C++ de votre projet.

Mis à jour le 18 avril 2005 Aurelien.Regat-Barrel

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

Mis à jour le 18 avril 2005 Aurelien.Regat-Barrel

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 :

Code c++ : Sélectionner tout
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; 
}
Code : Sélectionner tout
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.
Il ne s'agit pourtant pas de fuite mémoire mais d'une fonctionnalité de la bibliothèque standard. En effet, celle-ci peut posséder son propre espace d'allocation afin d'optimiser les performances, celui-ci n'étant pas libéré et rendu à l'OS une fois votre programme terminé. Mais pas de panique, la quantité de mémoire non libérée est constante et ne grossira jamais, peu importe le nombre d'objets que votre programme manipulera.

Toutefois, si cette fonctionnalité vous gêne vraiment vous pouvez la désactiver et forcer l'allocation « classique » :
  • 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

Cependant n'oubliez pas que ce comportement est un cas isolé, et que 99 % des fuites mémoires seront dues à des erreurs de votre part. Avant d'incriminer la bibliothèque standard, pensez à faire un maximum de tests !

Mis à jour le 17 octobre 2005 Laurent Gomila

Proposer une nouvelle réponse sur la FAQ

Ce n'est pas l'endroit pour poser des questions, allez plutôt sur le forum de la rubrique pour ça


Réponse à la question

Liens sous la question
précédent sommaire
 

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2019 Developpez Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.