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.