Pendu en C

Juste pour info, tu peux définir le typedef à la définition de la structure:

Bref,
Effectivement lorsque tu fais un tableau statique: type var[taille], alors taille doit être une constante: la variable est alloué statiquement. Quand le compilateur vois ça, il sait très bien qu'il aura besoin de (taille*sizeof(type)]) octets à allouer sur la pile, alors il peux le préparer à l'avance. Si tu veux mettre un tableau de taille non défini à la compilation, il va falloir que le programme alloue lui-même la mémoire dont il a besoin. C'est donc effectivement une allocation dynamique sur le tas qu'il te faut faire.

Par contre, je pense que tu galère parce que ta fonction COUNT_L() ne fait pas ce que tu en attends d'elle.

Tu n'incrémentes jamais i => boucle infinie si la chaine n'est pas vide.

Je te corrige:

mais tu peux faire plus simple (un for qui ne fait rien):

Bon, je ne teste pas ton programme, je lis juste rapidement, et je te dis mes remarques:
dans nombreAleatoire(), ne fait pas le srand() à chaque fois que tu souhaites un nombre aléatoire. Tu le fais une fois au début, et après tu n'utilises que rand(). En faisant comme tu fais, sans parler de la loi du khi², tu n'es pas sûr d'avoir un bon générateur aléatoire.

Dans ta fonction compare(), tu peux optimiser en arrêtant la boucle lorsque "chaine1[i] == chaine2[i]". Tu peux aussi faire un for qui ne sert à rien.
Sinon le strcmp retourne -1 (si chaine1[i] < chaine2[i]), 0 ou 1.

Sinon des petites règles pour bien utiliser malloc:
- quand tu écris le code malloc, la première chose à faire ensuite, c'est d'écrire la ligne du free()
- tester tous les pointeur lorsque avant l'utilisation de tout *var ou var->...

Quand tu fais un malloc, le contenu n'est pas mis à 00. Donc, soit tu fais un memset() avec '\0' pour mettre '\0' partout, soit (et c'est mieux), tu mets juste '\0' au premier caractère pour indiquer une chaine vide.
Lorsque tu fais une copie, il faut toujours penser à copier un caractère de plus pour copier le '\0', et quand tu initialise une chaine avec des '*', pense à ajouter un '\0' à la fin.
Bref, si tu penses toujours au '\0', tu n'aura jamais besoin d'utiliser un nombre de caractères (c'est l'avantage des fonction str...() sur les mem...() pour les chaines de caractères).

En fait le rand() est une fonction mathématique simple qui se base sur au moins une valeur précédente pour calculer la suivante. Par exemple: RAND<n> = (a * RAND<n-1> + c) % m où a,c et m sont des constantes.
Donc pour que rand() fonctionne bien, il faut l'avoir utilisé, mais au début on ne l'utilise pas, il faut donc définir une première valeur pour commencer. La première valeur c'est la graine (=> seed => seed random => srand) srand permet d'initialiser le générateur de nombres pseudo-aléatoire.
Afin d'avoir une séquence différente à chaque démarrage du programme, on utilise la valeur du temps actuel (time()), donc on a une valeur différente à chaque démarrage, ce qui donne une séquence différente.
Donc, le srand(), tu ne le lances qu'une seule fois pour initialiser le générateur de nombres pseudo-aléatoires, et pour obtenir des nombres aléatoires, tu n'utilises plus que rand().

Ce que je veux dire, c'est que toi tu recherches tous les caractères différents, mais si tu trouve un caractère différent, tu sais que les chaines sont différentes, alors il faut arrêter la boucle.
Exemple, si tu compares les 2 chaines suivantes:
abzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
abyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
1. Tu commences à lire 'a' == 'a', alors on continue à chercher une différence
2. 'b' == 'b' alors on continue à chercher une différence
3. 'z' > 'y' donc on sait que les chaines sont différentes, alors on s'arrête là et on gagne du temps à ne pas lire les autres caractères.

Le for ne fait rien mais boucle tant que l'on n'arrive pas à l'a fin d'un chaine et tant que les caractères sont identiques. Donc, après le for, i indique soit une fin de chaine, soit un caractère différent.

Bonjour à tous,

-Pour le '\0', tu veux dire quoi par initialiser toute la chaîne ?
Peu importe la valeur que tu affectes à ta variable au départ, celle-ci sera initialisé même lorsque tu fais:

-En ce qui concerne la fonction nombreAleatoire, le code est correct.
J'aimerais bien en savoir plus sur la loi de Khi² CRicky^^
Sinon ton code est correct.

-Pour compare(), je n'avais jamais vu un truc pareil concernant le code de CRicky car je n'ai pas l'habitude de faire des traitements dans les parenthèses du for, comme quoi on en apprend tous les jours
Si j'ai bien compris dès qu'une des conditions (cond_1 && cond_2 && cond_3) n'est plus vérifiée, il suffit de retourné la différence des 2 cases comparées qui sera différente de 0, donc "chaines non identiques".
Si ça retourne 0, elles sont identiques, c'est bien ça ?

Pour i++: on retourne la valeur et après on l'incrémente.
Pour ++i: on incrémente la valeur et on la retourne.

Après je ne vois pas pourquoi il a choisi "++i" ici

A+

Quand je parlais du '\0', ce que je voulais dire c'est que comme la chaine se termine toujours par '\0' en C, peu importe ce qui suit en mémoire puisqu'on ne va jamais le lire.
En C quand on écrit "toto", en fait, une fois compilé, c'est un tableau des caractères 't', 'o', 't', 'o' et '\0'. Du coup, quand on fait char var[] = "", et bien en fait on met un '\0' à l'adresse indiqué par var.

Pour ta fonction aléatoire, ça va marcher, mais moi, je pensais à quelque chose de beaucoup plus simple.
Dans le main:

Comme ça au tout début de ton programme, tu initialises le générateur, et après tu n'utilise que rand:

Pour le "return chaine1[i] - chaine2[i];", un caractère char est en fait un nombre codé (ASCII étendu ou latin-1) sur 1 octet, donc c'est juste un nombre de 0 à 255 inclus, avec par exemple '\0' = 0x00, '0' = 0x30.
Du coup, on compare les caractère par rapport à la position dans la table ASCII.
Donc si chaine1[i] == '\0' et chaine2[i] == '\0', ça retourne 0x00 - 0x00 = 0x00 => égalité.
si retourne < 0, alors la première chaine est soit plus courte, soit alphabétiquement (enfin suivant l'ordre ASCII...) avant la seconde.

pour le ++i et i++, akred3 a expliqué, alors je vais juste montrer la différence d'implémentation et vous expliquer pourquoi je n'utilise que des pre-incrémentation (++i). Si je code ++i par une fonction "int PreIncrement(int*)" et i++ par une fonction "int PostIncrement(int*)", alors l'implémentation sera:

Pour le post-increment, on doit passer par une valeur temporaire. Un "int" faisant généralement 4 octets, ça occupe 4 octets supplémentaire sur la pile à l'exécution. 4 octets ce n'est pas beaucoup donc, ça ne sert à rien de se limiter à ++i, on peut faire i++, ça ne changera rien.
En fait, c'est surtout en C++ que ça peut impacter, car si l'on fait la même chose avec des objets, ça crée un objet temporaire avec allocation d'une certaine mémoire, et appel du contructeur par recopie (en espérant qu'il n'ait pas de bug). Bref, c'est surtout en C++ en manipulant les objets que ça a un impact, c'est pourquoi, je prend toujours l'habitude d'utiliser le pre-incrément ++i. Je n'ai pas fait ça pour faire cette explication, c'est juste une habitude.
Même si i++ semble plus naturel que ++i, en fait, d'un point de vue logique, il est plus naturel de faire ++i, mais bon, tant que ce ne sont que des types de base, ça ne changera pas grand chose.

Pour le khi² en fait c'est le test du khi². C'est du calcul statistique (j'aime pas les stats ) qui permet de savoir si les valeurs correspondent bien à une distribution probabilistique (enfin il y a des dérivés du test).
http://fr.wikipedia.org/wiki/Test_du_khi_carr%C3%A9

Oui c'est ça.

Juste avant le "return -1;", affiche le code ASCII du caractère pour voir ce qui se passe:

C'est peut-être dû à un retour chariot qui traine, il faudrait peut-être vider le buffer du clavier après avoir entré la lettre.

Je dirais que ça dépend de ton compilateur et de son optimisation. Quoi qu'il en soit, du point de vue du programmeur, tu ne dois pas considérer que le reste est à 0. Si tu veux des 0, il faut faire un memset().

C'est un problème de logique: si A et B sont des conditions, alors NON(A ET B) <=> (NON A) OU (NON B) (il faut inverser ).
Concrètement, while( chaine1[i] != '\0' && chaine2[i] != '\0' && chaine1[i] == chaine2[i] ) relance une boucle si chaine1[i] != '\0' et chaine2[i] != 0 et chaine1[i] == chaine2[i]. Tu veux continuer la boucle si toutes les conditions sont vraie (donc utilisation de && ).
Du coup, comme il faut que toutes les conditions soient vérifiées pour continuer la boucle, il suffit qu'une seule des conditions ne soit pas vérifiée pour que la boucle ne continue pas, et donc s'arrête.
Donc, la boucle s'arrêtera lorsque qu'une des conditions n'est pas vérifié: ça boucle jusqu'à ce que chaine1[i] == '\0' ou que chaine2[i] == '\0' ou que chaine1[i] == chaine2[i].
En C, le "tant que" n'existe pas, donc il faut penser aux conditions pour que la boucle continue (et pas celles qui la font s'arrêter).

Dans une console de type DOS, de 128 à 255, c'est de l'ASCII, et sous windows (en fenêtre).

En fait, un char (comme un short et un int) est nombre signé. Donc, comme le char est codé sur 1 octet, il va en fait de -127 à 128 inclus. Du coup, si tu prends 0xEE ça code en fait -1, et dans le printf, il y a un cast implicite du char vers l'int, et ça se conde dans l'int: 0xFFFFFFFF.
Pour éviter le problème, il faut le convertir (cast explicite) en "unsigned char" qui est la version non signé (de 0 à 255):
Essaie ceci pour avoir le vrai nombre:

Pour ton exemple, tu as 0x8A qui est en fait 0x8A = 0xFF - 0x76 + 1. Donc, en signé 0x8A = -0x76 = -118 et ça se code en int: -118 = 0xFFFFFFFF - 0x76 + 1 = 0xFFFFFF8A

Je pense avoir compris ton problème:

Que retourne cette fonction sous XP et sous Vista ?

Hello =)

Oki, compris. Je supposte que tu voulais dire chaine1[i] != chaine2[i] au lieu de == à la fin de ton avant dernière phrase

Tu veux dire 0xFF plutôt pour -1 ? C'est donc le printf qui fait ce cast ? Il suffit donc que je définisse un unsigned char dès le début ?

Bah sous Vivi, elle marche très bien.

Et sous XP, je viens de rajouter des return 0 dans le if et else if et là ça semble marcher, bizarre non ???

La fonction retournait automatiquement -1 ou quoi ? et que sous xp en plus ?

Pas très compréhensible tout ça ...

Hey ,

Ceci dit, pour le %d du printf, d'accord, il attend un entier. Mais à ce moment-là, pourquoi n'affiche-t-il pas un nombre négatif tout simplement au lieu de faire un cast ?
(si c'était un entier, c'est bien ce qu'il ferait pourtant)

Pour l'exe, bah en fait non. J'avais copié/collé mon exe de mon visa à mon xp et ça ne marchait pas.
FInalement, j'ai recompilé sur les deux avec les return 0, et ça marche bien

Tant que j'y suis, j'aurais une petite question par rapport au buffer !

L'autre jour, j'avais manipulé fgets, etc..

J'avais fait cette fonction :

qui marchait bien au début et qui ne marchait plus ensuite ^^

Le truc pourri là-dedans, c'est que ça faisait un scanf et getch() même si la chaîne était de bonne taille, ce qui est gênant.

Alors j'ai voulu faire un test sur le buffer, pour faire cette étape uniquement si besoin !

Alors j'ai essayé de voir comment tester le buffer :

Le seul truc qui me donnait quelque chose de très cohérent, c'est avec le %d (je comprends pas pourquoi ça donne pas la même chose avec le %d et le %i enfin bref). Par exemple, la chaîne que j'introduis au départ est chaine[10], donc accepte 9 caractères.

Si je tapais lors de ma saisie : baptiste (8 caractères), donc + \n et \0 (\0 rajouté par fgets si j'ai compris ?), le %d m'affichait 0. Si je faisais plus, ça m'affiche toujours quelque chose de très cohérent, par ex :



Là, il m'affiche le 5 et c'est cohérent puisque il reste iste\n (je pensais qu'il y avait encore le \0 après, mais apparemment ou bien ça compte pas comme caractère (puisque c'est null) ou bien c'est rajouté par fgets uniquement pour la chaîne qu'il maitriste). Finalement je me demande si un scanf ("%*[^\0]" ); ne suffirait pas pour vider le buffer !)

Donc je me suis dit qu'à partir de là, je pouvais faire un test sur le buffer en faisant un truc du genre :

if (*stdin != 0)
{
scanf ("%*[^\n]" );
getch();
}

Le problème c'est que ça ne compile pas =D

Mais j'ai cru comprendre sur ce lien : http://www.linux-kheops.com/doc/ma [...] din.3.html que stdin (ou stdout, stderr) était un pointeur de type FILE.. Bref, je sais pas tropcomment faire. =D

Thanks ! GTB

Hello,

D'accord, maintenant, je crois avoir compris pour ce fameux cast ! Je n'avais jamais entendu parler de cette astuce pour voir combien fait un nombre (négatif ) = 0xFF (nombre de bits ...) - 0xle nombre qu'on cherche si bit de poids fort à 1 = le nombre qu'on cherche (en mettant - devant). Ou sinon complément à 2

Pour décompiler, je veux bien, mais je sais pas trop comment faire.. (comment utiliser surtout)

Ok pour le type file. Mais tu vois bien que quand je fais un %d, *stdin, cela m'affiche le nombre de caractères dans le buffer ? (\0 exclu bien-sûr !)

En fait dans ma fonction READ, j'espérais m'en servir pour faire le scanf ("%*[^\n]" ) (supprime les caractères compris dans le buffer sauf les \n suivi d'un getchar(), je me demandais d'ailleurs si on pouvait pas plus simplement faire scanf ("%*[^\n]'). (vu ça sur un tuto de developpez.com). Tu veux le lien ?

Donc en fait j'aurais bien aimé me servir de ce *stdin, mais si c'est pas vraiment possible, tant pis :þ

Hey !

Juste pour revenir là-dessus ! La conversion en int ne semble que se faire que lorsque le nombre est négatif, c'est bizarre tout de même

J'utilise CodeBlocks comme interface de développement Je veux bien essayer, ça me ferait une expérience =)

Pour le stdin, tu as une idée pourquoi le résultat est différent selon que je fasse %i et %d (ce qui était la même chose je pensais ! ). Sinon, bien-sûr, je ne connais pas cette structure, donc pas moyen de me servir de mon résultat avec %D pour tester si le buffer est vide ou pas ? Ce serait intéressant tout de même =) Sinon je ne vois pas trop comment tester le buffer, car j'aimerais faire des scanf ou getchar seulement si le buffer est plein (en gros pour pas que ça demande à l'utilisateur de taper quelque chose s'il a bien respecté les règles pour la saisie d'avant).

Pour moi, le problème avec cette fonction (du sdz) :

void viderBuffer()
{
int c = 0;
while (c != '\n' && c != EOF)
{
c = getchar();
}
}

C'est qu'on a au moins un getchar(), ce que je veux éviter. Sinon pour le EOF, je suppose que ça marque la fin : '\0' ? ..

Voici le link pour scanf : http://xrenault.developpez.com/tutoriels/c/scanf/

Hello !

Voici pour le Debug, je crois que c'est bon (j'ai enlevé les return0 ajoutés évidemment).

Merci pour les autres infos !

PS : J'ai l'impression que je n'arrive à désassembler que cette fonction, pas encore saisi le fonctionnement. Je fais des Debug, et quand il me le permet (pour désassembler) "debug - next instruction"

Hello,

Intéressant cette analyse

Ici, par curiosité, où est le supérieur à et inférieur à ?
Ou alors c'est jle et jg qui précisent cette différence C'est sûrement ça, je me souviens, on en avait parlé. Les différents jump se réfèrent à une valeur précise dans certains bits du registre EFLAGS et jumpent en conséquence.

Faudrait que je lise la doc ASM..

Merci

Oki, merci pour toutes ces infos