Le mystère du mode debug sous dev c++

Le mystère du mode debug sous dev c++ - C++ - Programmation

Marsh Posté le 04-02-2006 à 16:18:08    

Bonjour les gens, c'est mon premier post sur ce forum, j'espère ne pas avoir sauter LE sujet qui m'aurait dépanné ^^
 
Je vous présente donc mon projet : il s'agit d'un moteur 3d openGL sous windows, développé sous devc++
le but actuel de mon code est de charger un fichier .3DS, puis de l'afficher en couleur unie dans la fenêtre opengl, et permettre de tourner autour avec la souris. en plus de l'affichage 3d, et une "interface" (pour l'instant qq rectangle) vient se greffer en transparence au dessus de cette vue 3d.
 
jusque là, rien de bien compliqué (quoique le code commence à être impressionnant), et tout fonctionnait jusqu'alors.
 
Et maintenant, le drame : après de multiple modification (haaaan il a pas noté les modifications qu'il a faites, spabieeeeen) le problème suivant arrive :  
 
-lors de la compilation du code : aucune erreur.
-lancement de l'application : le fichier 3DS est chargé (confirmation de lecture du fichier dans une fenêtre dos), mais pas affiché. pourtant l'interface en transparence est bien affichée. on pourrait pensé que j'ai bêtement effacé la ligne qui permet d'afficher le modèle chargé mais...
-lancement de l'application en mode debug : tout est à sa place.  :ouch:  Oui, l'interface, le modèle 3DS, tout es affiché.
 
Pour conclure : est-ce que qqn a une idée de l'endroit où j'ai merdé ? Que puis-je vous donner comme informations pour vous aider ?

Reply

Marsh Posté le 04-02-2006 à 16:18:08   

Reply

Marsh Posté le 04-02-2006 à 19:54:05    

t'as du code complètement pourri qui se comporte pas pareil en debug et release.

Reply

Marsh Posté le 04-02-2006 à 21:24:35    

Avec dev-C++ comme avec Visual C++ ou d'autres compilateur, la cause la plus courante qui fait qu'un programme marche en debug et plante en mode release est l'absence ou la mauvaise intialisation d'espace mémoire.
 
En effet, la plupart du temps, en mode debug, le debugger met à zéro la mémoire avant d'exécuter le programme, alors qu'en mode release la mémoire peut contenir tout et n'importe quoi.
 
Il arrive que les programmeurs pensent à tort, qu'en C/C++ la mémoire est initialisée implicitement comme ça l'est en basic. Ou bien une faute d'inattention fait qu'on initialise toto1, alors qu'il faut initialiser toto2. Ou bien on oublie qu'il faut que les chaines de charactères se terminent par un caractère nul. Ou bien, on croit à tort que sizeof() renvoie toujours la bonne taille, alors que ce n'est le cas que dans des conditions particulières. Etc.
 
Il faudrait voir le programme pour détecter ce qui ne va pas.

Reply

Marsh Posté le 05-02-2006 à 14:08:39    

olivthill a écrit :

on croit à tort que sizeof() renvoie toujours la bonne taille, alors que ce n'est le cas que dans des conditions particulières. Etc.


 
qu'est ce que tu veux dire ?

Reply

Marsh Posté le 05-02-2006 à 14:26:03    

que soit on connait l'opérateur sizeof, soit pas.

Reply

Marsh Posté le 05-02-2006 à 14:30:52    

en effet, c'est ce que j'ai compris

Reply

Marsh Posté le 05-02-2006 à 14:37:41    

olivthill a écrit :


En effet, la plupart du temps, en mode debug, le debugger met à zéro la mémoire avant d'exécuter le programme, alors qu'en mode release la mémoire peut contenir tout et n'importe quoi.


 
a 0, non, ca serait une grave erreur de la part du compilo (IMHO) generalement y mettent plus des valeurs alacon genre 0xcd

Reply

Marsh Posté le 05-02-2006 à 15:44:16    

Citation :

Citation :

on croit à tort que sizeof() renvoie toujours la bonne taille, alors que ce n'est le cas que dans des conditions particulières. Etc.


qu'est ce que tu veux dire ?


sizeof() peut parfois prêter à confusion.
 
Par exemple, sizeof() est différent de strlen() pour plusieurs raisons dont une qui est que sizeof renvoie une taille qui est calculée lors de la compilation et non pas lors de l'exécution du programme.
 
Autre exemple, en fonction du contexte, sizeof() peut renvoyer soit la taille d'une chaine de caractères, soit la taille du pointeur sur une chaine de caractères, voir le code ci-dessous, ou sizeof() renvoie 4 ou 100.

void print_sizeof_in_sub(char s[100])
{
   printf("sizeof(s)=%d.", sizeof(s));
   // "sizeof(s)=4."
}
 
int main(void)
{
   char s[100];
   printf("sizeof(s)=%d.", sizeof(s));
   // "sizeof(s)=100."
 
   print_sizeof_in_sub(s);
   exit(0);
}

Reply

Marsh Posté le 05-02-2006 à 16:12:06    

Citation :


Par exemple, sizeof() est différent de strlen() pour plusieurs raisons dont une qui est que sizeof renvoie une taille qui est calculée lors de la compilation et non pas lors de l'exécution du programme.


 
sizeof renvoi la taille du type d'un identifeur ou d'un type, c'est opérateur du langage et c'est résolu statiquement ('sizeof x' est une expression constante). Une chaine litterale est de type tableau de char (comme un identifieur de type tableau c'est l'adresse de sont premier element), donc aucune confusion car sizeof renvoi bien la taille du tableau
 

Citation :

Autre exemple, en fonction du contexte, sizeof() peut renvoyer soit la taille d'une chaine de caractères, soit la taille du pointeur sur une chaine de caractères, voir le code ci-dessous, ou sizeof() renvoie 4 ou 100.


 
tu vois tu n'as pas vraiment compris ce que retourne sizeof, la encore pas de confusion, dans le main s est de type tableau de 100 char donc sizeof renvoi 100, dans la fonction s est de type pointeur de char qui au moment de l'appel pourra se voir affecter l'adresse d'un tableau de char (en c++ on ne peut pas passer de tableau par valeur) donc sizeof retourne la taille du pointeur
par contre si tu avais passer le tableau par référence sizeof aurait retourné 100...
 
d'ailleur tu ecris

Code :
  1. void print_sizeof_in_sub(char s[100])


et c'est peut etre pour ca que c'est confus pour toi, en réalité ce prototype est strictement équivalent à

Code :
  1. void print_sizeof_in_sub(char s[])


et à

Code :
  1. void print_sizeof_in_sub(char *s)


Reply

Marsh Posté le 05-02-2006 à 18:36:06    

hé bien je vous remercie, pour ces remarques, surtout olivthill... je vais vérifier mes réservations et libérations mémoire.
 
Par contre Taz, merci, je me doutes que mon code chie qqpart ;)  

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed