M�me si j'avance mon nouveau projet en parall�le, je reste coinc� quant � celui-ci : personne ne peut m'aider, svp ?
Version imprimable
M�me si j'avance mon nouveau projet en parall�le, je reste coinc� quant � celui-ci : personne ne peut m'aider, svp ?
d'autre part, � ce sujet, j'avais d�j� signal�, mais je me demande bien pourquoi on met
et non pasCode:#define bool int
ce qui fait quand m�me �conomiser 3 octets par valeur.... (en moyenne ;) )Code:#define bool char
je dirais m�me plus : syst�matiquement l'usage d'un debugger ou d'un outil incluant un debugger modifie le comportement vis-�-vis de la m�moire... car en g�n�ral il "surveille" gr�ce � ses propres mallocs/frees, et est lui-m�me en g�n�ral charg� ;) ce qui modifie signaficativement les segments utilis�s...Citation:
Envoy� par kidpaddle2
Et enfin c'est un comportement symptomatique bien connu d'un probl�me de fuite de m�moire..
et en passant rapidement sur le code original, je m'aper�ois que :
- Pas de test si les allocations/r�allocations se sont correctement effectu�es.
- Donc des copies et des frees potentiellement erron�s
- Une erreur de longueur d'allocation (d�bordement) :
Code:
2This->list[This->count-1] = malloc( (strlen(path)+1) * sizeof (char));
En passant en 3 minutes...
...mais peut augmenter la taille du code (et le temps d'execution) s'il y a beaucoup de conversion a faire vers int. Si on est limite en memoire, char est bon choix. Sinon, il y a peu de raisons de ne pas utiliser int.Citation:
Envoy� par souviron34
bah � ce compte-l� pourquoi utiliser un bool�en ??Citation:
Envoy� par DaZumba
c'est bien 0 ou 1, si mes souvenirs sont bons :aie:
Donc pourquoi stocker dans une variable qui peut aller jusqu'� INT_MAX ??
256 valeurs c'est d�j� largement suffisant pour en repr�senter 2....
Et si il y a beaucoup de conversion vers int c'est qu'on a mal choisi sa variable....
Je rappelle que les param�tres de fonction sont facilement promus en Int, et que les procs les plus rapides ne savent pas faire des op�rations (m�me des comparaisons � z�ro) sur plus petit...
... et je complete que la norme precise que le resultat des operateurs relationnels (< > <= >=) et des operateurs d'egalite (== !=) est de type int (6.5.8, 6.5.9). int est donc un type naturel pour quelque-chose qui se retrouve dans un if()...Citation:
Envoy� par M�dinoc
Exactement. Perso, je n'en ai jamais eu besoin...Citation:
Envoy� par souviron34
Moi une seule fois, pour compl�ter des types de donn�es (r�els, entier, chaines, char, et bool�en (donc char ;) ) ).Citation:
Envoy� par DaZumba
Le d�bat portant sur la justification d'un type bool�en fait rage, � ce que je vois, mais je rappelle que ce n'est pas le sujet de ce topic. En revanche, suite � une des r�ponses de souviron34 -que je remercie donc, en plus de ceux qui ont daign� r�pondre ^^ -, que voil� :
Avec cette modification, le programme s'ex�cute sans probl�me, que ce soit en mode release ou debug. Apr�s avoir r�fl�chis un peu par la suite, j'ai �mis l'hypoth�se que cette distinction debug/release soit due � une potentielle initialisation du segment de m�moire utilis� par le programme (par le debugger) � 0. Ainsi, l'absence du caract�re NULL final serait combl�e par sa pr�sence au sein du reste de la m�moire...Citation:
Une erreur de longueur d'allocation (d�bordement) :
Code:This->list[This->count-1] = malloc( (strlen(path)+1) * sizeof (char));
Enfin bref, tout �a pour dire que l'aiguille a finalement �t� trouv�e dans cette botte de foin, et que le sujet est cons�quemment r�solu ;)
Merci � vous tous.