| ||
auteur : Aurélien Regat-Barrel | ||
Parfois, on est confronté à des problèmes très étranges et apparemment sortis de nul part:
Ces disfonctionnement 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:
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:
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...).
|
| ||
auteur : Aurélien Regat-Barrel | ||
Sous Windows, quand on lance un programme console depuis certains IDE (tel que devcpp), 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:
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) ?.
|
| ||
auteur : Anomaly | ||
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.
|
| ||
auteur : Aurélien Regat-Barrel | ||
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 du 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. |
| ||
auteur : Aurélien 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(). A 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.
|
| ||
auteur : Aurélien Regat-Barrel | ||
Oui, mais de manière confortable à partir de Visual C++ 7.1 seulement (Visual C++ .Net 2003).
Microsoft a consacré un article à ce sujet qui fait aussi office de bonne introduction à cette bibliothèque : Boost for Visual C++ Developers.
L'article Installer et utiliser Boost/Boost.TR1 avec Visual C++ vous donnera les bases pour réaliser cette installation
|
| ||
auteur : Aurélien Regat-Barrel | ||
L'implémentation de la STL livrée avec Visual C++ 6 possède divers bugs. Il est vivement conseillé de procédé à 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.
|
| ||
auteur : Aurélien 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.
|
| ||
auteur : Aurélien Regat-Barrel | ||
Vous trouverez des solutions à divers problèmes spécifiques à Visual C++ dans la FAQ Visual C++.
|
| ||
auteur : Laurent Gomila | ||
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 :
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 !
|
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 © 2008 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site ni 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.