Discussion :

[kidpaddle2]

M�me si j'avance mon nouveau projet en parall�le, je reste coinc� quant � celui-ci : personne ne peut m'aider, svp ?

[souviron34]

d'autre part, � ce sujet, j'avais d�j� signal�, mais je me demande bien pourquoi on met

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

#define bool int

et non pas

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

#define bool char

ce qui fait quand m�me �conomiser 3 octets par valeur.... (en moyenne )

[souviron34]

Tr�s int�ressante la comparaison avec le principe d'incertitude... par ailleurs, d'apr�s ce que je vois, le mode debugger allouerait plus de m�moire qu'il n'en est n�cessaire (je suis sous Code::Blocks) ?

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


Et enfin c'est un comportement symptomatique bien connu d'un probl�me de fuite de m�moire..

[souviron34]

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 :

  S�lectionner tout - Visualiser dans une fen�tre � part

  1
  2
      This->list[This->count-1] = malloc( (strlen(path)+1) * sizeof (char));

En passant en 3 minutes...

[DaZumba]

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

#define bool char

ce qui fait quand m�me �conomiser 3 octets par valeur...

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

[souviron34]

...mais peut augmenter la taille du code (et le temps d'execution) s'il y a beaucoup de conversion a faire vers int.

bah � ce compte-l� pourquoi utiliser un bool�en ??

c'est bien 0 ou 1, si mes souvenirs sont bons

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

[M�dinoc]

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

[DaZumba]

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

bah � ce compte-l� pourquoi utiliser un bool�en ??

Exactement. Perso, je n'en ai jamais eu besoin...

[souviron34]

..Exactement. Perso, je n'en ai jamais eu besoin...

Moi une seule fois, pour compl�ter des types de donn�es (r�els, entier, chaines, char, et bool�en (donc char ) ).

[kidpaddle2]

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� :

Une erreur de longueur d'allocation (d�bordement) :

Code C :

S�lectionner tout - Visualiser dans une fen�tre � part

This->list[This->count-1] = malloc( (strlen(path)+1) * sizeof (char));

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

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.