Voici un soucis que j'ai eu aujourd'hui et qui m'as fait perdre deux bonnes heures de boulot pour RIEN !
Bon, c'est en relation avec Microsoft Windows(c) mais ça prouve bien que même le B-A-BA du fonctionnement d'un logiciel et biaisé par l'OS, et provoque donc des plantages là où ça ne devrai pas.
Alors voici mon problème, je suis en cours de portage d'une de mes applications vers Windows(c)... :-(
Remarquant un bug d'une valeur, je part à la chasse au bug pour finalement isoler le bug suivant :
Même un développeur de base comprendra ce code.
Et voici le résultat de l'exécution sous Windows (aucun soucis sous linux) :
Prend 800.000000 * 0.750000 * 0.600000 = 360.000000 ( 359 ) = 360.000000 ( 360 )
Peut-t-on m'expliquer ce que fou là ce 359 !? Windows compte mal à ce point ?
Ca m'inquiète sincèrement sur la qualité d'application même bien développé...
Pour information, ça a été compilé avec g++ 3.4.4 sous Windows.
PS: A la base, je voulais poster ça dans le forum de developpez.net (qui est mieux pour les questions dev), mais il est HS. Donc j'ai voulu mettre sur ce forum, qui n'est pas accessible non plus, donc en désespoir de cause, je poste ici :-)
Bon, c'est en relation avec Microsoft Windows(c) mais ça prouve bien que même le B-A-BA du fonctionnement d'un logiciel et biaisé par l'OS, et provoque donc des plantages là où ça ne devrai pas.
Alors voici mon problème, je suis en cours de portage d'une de mes applications vers Windows(c)... :-(
Remarquant un bug d'une valeur, je part à la chasse au bug pour finalement isoler le bug suivant :
double a = 800.0 ;
double b = 0.75 ;
double c = 0.6 ;
double d = a*b*c ;
printf("Prend %f * %f * %f = %f ( %i ) = %f ( %i ) %\n", a, b, c, a*b*c, (int)(a*b*c), d, (int)d) ;
Même un développeur de base comprendra ce code.
Et voici le résultat de l'exécution sous Windows (aucun soucis sous linux) :
Prend 800.000000 * 0.750000 * 0.600000 = 360.000000 ( 359 ) = 360.000000 ( 360 )
Peut-t-on m'expliquer ce que fou là ce 359 !? Windows compte mal à ce point ?
Ca m'inquiète sincèrement sur la qualité d'application même bien développé...
Pour information, ça a été compilé avec g++ 3.4.4 sous Windows.
PS: A la base, je voulais poster ça dans le forum de developpez.net (qui est mieux pour les questions dev), mais il est HS. Donc j'ai voulu mettre sur ce forum, qui n'est pas accessible non plus, donc en désespoir de cause, je poste ici :-)
> Lire le journal (49 commentaires, moyenne: 4,1).
Vous avez demandé le commentaire #859591.
Run by 
Cette page a été générée par Templeet en 0.0444s (dont 0.0047 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
de plus...
en plus des explications ci-dessus concernant les problèmes d'arrondis, pour afficher un double, il est préférable d'utiliser %lf ou %g.
Le %f n'affiche le double qu'avec une précision de float... donc il y a encore des risques d'imprécisions.
[^]Re: de plus...
pas du tout efface.
Extrait de la doc gnu libc :
The `%f' conversion prints its argument in fixed-point notation, producing output of the form [-]ddd.ddd, where the number of digits following the decimal point is controlled by the precision you specify.
et plus loin :
Without a type modifier, the floating-point conversions use an argument of type double. (By the default argument promotions, any float arguments are automatically converted to double.)
et man printf est d'accord :
f,F The double argument is rounded and converted to decimal notation in the style [-]ddd.ddd, where the number of digits after the decimal-point character is equal to the precision specification.
sinon, %g choisi automatiquement la representation la plus lisible suivant la valeur de l'argument (%f ou %e). et %lf est invalide.
[^]Re: de plus...
ok, j'ai rien dit...
mais bon, j'ai souvenir que dans certains de mes programmes, je préférais voir le résultat en %g qu'en %f... enfin, ça dépend de tellement de paramètres...