Version imprimable
Bonjour les amis .. Je suis un nouveau membre dans votre Forum ..
j'ai un petit problème concernant la fonction atof() de la bibliothèque <stdlib.h> .. qui convertit une chaine de caractère en un double ..
les fonctions atoi() , atol() marchent tres bien ..
mais celle ci ( atof() ) ne marche pas .. quand j'entre un chaine de caractere par exemple 123.123marcosa elle retourne 0.00000 normalement ca doit être 123.123 ..
voici le photo du petit problème : Pièce jointe 429606
et merci (y) ;
Bonjour MouadCitation:
Envoyé par MouadCR7
Rajoute #include <stdlib.h> qui contient le prototype de atof() (en plus tu la connais puisque tu en parles dans ton titre !!!). Sans ce prototype, le compilateur qui la voit pour la première fois dans ton code la qualifie en "int" (comme toute fonction non déclarée). Ensuite quand le float renvoyé par la fonction est casté en int, il passe à 0.Citation:
Envoyé par MouadCR7
Accessoirement il vaut mieux éviter d'utiliser gets() non sécurisée (ton compilateur as dû te le dire). Bon là ça va que c'est un petit truc rapide pour tester mais à l'avenir, si tu veux coder des trucs plus robustes, il vaudra mieux lui préférer fgets(str, 100, stdin) (100 parce que ta chaine est taillée à 100 bien évidemment). Et pareil, vaut mieux éviter le "tout majuscule" pour les noms de variables car c'est réservé aux macros.
Ben la prochaine fois tu mettras ton code directement dans ton post entre balises :tagcode: ce qui nous permettra de le récupérer sans avoir à le retaper.Citation:
Envoyé par MouadCR7
Bonsoir et bienvenue, l'erreur est due aux "marcosa" après les valeurs numérique saisie.
Si vous regardez attentivement le résultat que vous avez obtenu vous remarquerez que les fonctions atoi atol et atof acceptent uniquement les valeurs numériques, mais en revanche n'acceptent pas les valeurs non-numériques comme "azert123.123azerty". La chaîne de caractères qui vient après ou avants une série de valeurs ne peut donc être converties; d'où, le renvoi de la valeur zéro par ces fonctions.
Il est à noter également qu'il y a aucun moyen de savoir si la conversion a échoué. Soit vous saisissez uniquement des valeurs numériques du genre : 12345.12345, 12345.12345E+03 ou -12345.12345E-05, ou alors vous optez pour une alternative comme sscanf ou de la technicité avec les fonctions comme strtol() et strtoul() ( qui sont utilise par sscanf ) .
Il est également préférable que vous utilisiez la fonction fgets que gets pour des questions de sécurité, car, la fonction gets() ne vérifie pas la limite maximale des caractères d'entrée cela a pour conséquence un dépassement du tampon et écrasement d'autres informations; tant dis qu'avec fgets on s'arrêtera lorsque l'on atteints la limite fixé (n-1) qui est la taille du buffer/ tampon. Ainsi, si la chaîne lue est plus longue que le tampon de réception, aucun dépassement de mémoire ne sera effectué.
À bientôt,
Non. :nono:Citation:
Envoyé par sambia39
Si c'était la cause du souci, alors ça ne fonctionnerait pas non plus pour atoi() et atol(). Or, si tu regardes bien son image, on voit que ça fonctionne.
Il n'a pas entré "azert123.123azerty" mais "123.123marcosa" et là c'est bon car la fonction s'arrêtera au premier caractère non numérique et renverra 123.123.Citation:
Envoyé par sambia39
Non :nono:Citation:
Envoyé par sambia39
Elles renverront le maximum de ce qu'elles auront pu traiter.
ouuuupss xD grosse faute d'inattention , je me suis concentre sur les autres lignes , mais la question qui se pose pourquoi le compilateur l'a accepte , normalement ca aucun sens , et pourquoi il a accepte les autres fonctions sans <stdlib.h> ?Citation:
Envoyé par Sve@r
a propos de la fct gets , mon compilateur n'a pas mentionne aucune chose .. je vais essayer de lire le cours de ces nouveaux fonctions que je ne les connait pas ..
Je n'ai pas dit le contraire j'ai écris: "les fonctions atoi atol et atof acceptent uniquement les valeurs numériques, mais en revanche n'acceptent pas les valeurs non-numériques comme "azert123.123azerty". La chaîne de caractères qui vient après ou avants une série de valeurs ne peut donc être converties; d'où, le renvoi de la valeur zéro par ces fonctions." et azerty12345azerty est un exemple pour expliquer que la fonction ne convertissait pas les valeurs non-numériques.Citation:
Envoyé par Sve@r
je ne te suis pas, comment savoir le maximum que la fonction a traiter sachant qu'elle retourne une valeur qui est le résultat de la conversion ou zéro ?Citation:
Envoyé par Sve@r
Tu voulais plutôt dire qu'elle renvoie la valeur zéro parce qu'elle ne peut pas effectuer la conversion ?
Ces fonctions ont pour l'entrée (stdin) une chaine de caractère quel que soit ses types de ses éléments ... mais elles prennent juste la première partie numérique jusqu'au premier caractère qui est non numérique .. je te conseille de lire ce chapitre concernant des fonctions utilise pour les chaines de caractères .. a propos des autres fonctions que tu les a mentionne je vais essayer de les lire et voir la différences entre euxCitation:
Envoyé par sambia39
Et Merci
je n'ai pas trop compris ce que vous avez écrit pouvez-vous m'en dire plus ?
Voila quelque règles générales de la conversion en utilisant ces fonctions :
-Les espaces au début d'une chaîne sont ignorés .
-Il n'y a pas de contrôle du domaine de la cible .
-La conversion s'arrête au premier caractère non convertible .
-Pour une chaîne non convertible, les fonctions retournent zéro .
En regardant la règle numéro 3 , on peut appliquer ces fonctions dans une variable déclarée comme tableau de char , cette fonction prends juste la première partie numérique ( exp '1' , '2' , '3' , ... ) et s'arrête au premier caractère non numérique , mais en respectant ces consignes ..
J'espère que je t'ai aide .
Comme je l'ai dit, le compilateur considère toute fonction non déclarée comme "int".Citation:
Envoyé par MouadCR7
Possible. Ton compilateur ne doit pas être comme le mien (gcc standard sous Linux). L'important c'est que tu comprennes que gets() ne bloque rien donc permet potentiellement à l'utilisateur de saisir plus de caractères que ce que "str" peut en accepter.Citation:
Envoyé par MouadCR7
Tu parles de fgets(str, n, flux) ? Pas compliqué: cette fonction lit les données en provenance du flux jusqu'à concurrence soit d'un '\n' (caractère symbolisant un <return>) soit de "n-1" caractères lus (la première des deux conditions étant décisive). Et stocke le tout dans "str". Ca évite donc de saisir plus de caractères que ce que "str" peut accepter. Seul petit handicap: le caractère '\n' s'il est lu est lui aussi stocké ce qui peut parfois gêner mais un coup de strchr() pour le trouver et on le remplace par '\0' et c'est réglé.Citation:
Envoyé par MouadCR7
Ben 123.123marcosa converti en 123.123 était déjà un parfait exemple pour ça.Citation:
Envoyé par sambia39
Elle ne renvoie pas le résultat de la conversion ou zéro, elle renvoie le résultat de la conversion tout court (extrait du man: "RETURN VALUE: The converted value."). Et ce résultat dépend de ce qui a été converti. Dans "123.123marcosa" elle s'arrête au "m" mais a traité "123.123" donc c'est ce qu'elle renvoie. Et si elle renvoie 0 c'est parce que soit la chaine contient "000" soit elle ne contient aucun nombre donc que la fonction n'aura rien pu faire.Citation:
Envoyé par sambia39
Mais pourquoi il a accepte les autres fonctions ??Citation:
Envoyé par Sve@r
Je ne comprends pas ce que tu entends par "accepte". Il les accepte toutes dans le sens où il accepte de les appeler et n'en refuse donc aucune. Mais en C, une fonction doit être déclarée pour qu'elle soit connue. Si elle ne l'est pas, alors le compilateur accepte de la reconnaitre "à la volée" en quelque sorte mais il doit lui donner un type et il a été décidé que ce serait "int". Et mettre "int" une fonction renvoyant un float n'est pas ce qu'il y a de mieux si on veut avoir le bon résultatCitation:
Envoyé par MouadCR7
Et les autres étant déjà soit int (atoi) soit un type presque int (atol) ben là ça n'impacte pas l'exécution.
Si on détaille mieux, alors en fait c'est plus pernicieux que ça car même casté en int, 123.123 donne quand-même 123 et pas 0. Il faut aussi rajouter le "%f" de printf() qui rajoute en plus de la confusion à l'affichage
Exemple
printf("%d", (int)123.123) => affiche 123.
printf("%f", (int)123.123) => affiche 0. C'est dû au fait que le codage int/short/long est le même (123 donne 0x007B en short ou 0x0000007B en long) donc se tromper entre "%d" au lieu de "%hd" dans le cas d'un short/long ne gêne pas (trop) tandis qu'en float, le codage est totalement différent (avec la mantisse et l'exposant tout ça "123" donnera peut-être 0x7FFFFFF2 ce qui n'a plus rien à voir avec 0x007B). Et donc si on ne caste pas explicitement en float, printf() reçoit toujours "0x007B" qu'il ne sait pas reconvertir car c'est totalement inadéquat avec le codage "float" et affiche alors 0.
Et donc au final printf("%f", (float)((int)123.123)) => affiche bien 123.000 alors que printf("%d", 123.123) affiche "2147483634" (qui, traduit en hexa, donne pile poil 0x7FFFFFF2 !!!)
ahhh c bon merciii pour les infos .
Moralité : n'oublie pas d'activer à la compilation les avertissements qui pourraient être pertinents -Wall -Wextra -Wconversion..
