"The most important thing in the kitchen is the waste paper basket and it needs to be centrally located.", Donald Knuth
"If the only tool you have is a hammer, every problem looks like a nail.", probably Abraham Maslow
FAQ-Python FAQ-C FAQ-C++
+
Tu as raison. Je m'excuse j'ai mal regardé le nombre de pages. 94 pages. J'en ai 5 de faites lol. C'est un anglais clair, donc assez facile à suivre.
Je ramène également ma question, même si c'est probablement inutile.
C'est que je veux vraiment le savoir, car j'ai fait plusieurs programmes qui utilisent volontairement la troncature eet qui ne foncctionneraient pas sans elle.
Donc, est-il bien de tirer profit de la troncature des nombres à virgules dans les variables de type integer(entier)?
Par exemple comme dans l'exemple que j'ai donné. Qu'en pensez-vous?
Bonjour,
J'aimerais savoir si l'on peut donner de nouvelles valeurs aux macros de float.h.
Par exemple, FLT_EPSILON ou DBL_MAX ?
Peut-on simplement utiliser #define!?
Je ne crois pas que ce code serait valide, mais peu importe... Je ne fais que me questionner.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6 #include <stdlib.h> #include <float.h> #define DBL_EPSILON 1e-20 [...]
Merci,
Array
Tu peux.
Et si ça gueule, tu peux faire quelques #undef avant...
Par contre, je ne vois pas trop l'intéret (SURTOUT pour FLT_MAX)...
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Tu peux mais ça n'a aucun intérêt parce que ces valeurs sont là à titre indicatif et les changer ne changera en rien la précision ou les bornes des nombres...
C'est techniquement possible (avec un #undef) , mais le comportement devient indéterminé car une information appartenant à l'implémentation a été modifiée.
Si tu veux ton propre EPSILON, utilise ton #define :
Code : Sélectionner tout - Visualiser dans une fenêtre à part #defne MY_ESPILON (1e-20)
Eh bien.
Alors comment changer les comprtements rattachés aux macros de la bibliothèque standard? Si changer ces macros ne sert à rien...
Merci,
Array != 0
"The most important thing in the kitchen is the waste paper basket and it needs to be centrally located.", Donald Knuth
"If the only tool you have is a hammer, every problem looks like a nail.", probably Abraham Maslow
FAQ-Python FAQ-C FAQ-C++
+
Il n'y a pas à "changer le comportement de la bibliothèque standard". Pourquoi veux-tu faire ça ? Le comportent est en grande partie définie par la norme et le reste par l'implémentation.
En tant que programmeur, tu utilises cet outil, mais tu n'as absolument pas le droit de le modifier.
Que cherches-tu à faire exactement ?
Ah veuillez excuser le déficit de clarté que comportent mes propos.
Ce que je crois (plutôt ce que je croyais, car il semble que je me sois trompé), c'est qu'en changeant certains macros de la Bibliothèque Standard, on pouvais changer le comportement de la machine, et, par le fait même, le comportement des programmes.
Par exemple, en changeant FLT_EPSILON ou FLT_ROUNDS, si je fais (1.456 * 10), au lieu de donner 14.559999, la machine donnerait le vrai résultat, soit 14.56.
C'est ce que je veux dire.
Je croyais que si je changeais FLT_MAX, je pourrais par exemple, augmenter la valeur maximale que peut accepter un FLOAT.
Ce que je voudrais savoir, c'est si l'on peut changer ces comportements. . .
Je crois m'apercevoir, en voyant vos messages, que les macros de la StdBiblio ne sont qu'à titre indicatif, afin de donner au programmeur/ingénieur des informations sur la machine.
Si c'est bien cela, je découvre cependant que je pourrais arrondir 14.559999 en 14.56 en utilisant DBL_EPSILON.
Si cette question semble idiote - même si EmDel me prie de ne pas utiliser ce mot pour qualifier mes questions - pour plusieurs d'entre vous, je m'en excuse humblement. Veuillez excuser mon manque d'expérience, et si j'ai commis une bévue, vos réponses la corrigeront.
Cordialement,
Array
En effet, tu t'es fourré le doigt dans l'oeil jusqu'à l'épaule
Comme je l'ai dit plus haut, les macros ne sont là qu'à titre indicatif, elle t'indique comment, dans le processeur, les variables sont conçues, mais le processeur c'est du matériel gravé et immuable, tu peux en changeant du texte changer son comportement.
Absolument pas. Il est absolument interdit de bricoler quoique ce soit dans les headers fournis par l'implémentation.
Je ne vois pas ce qui a pu te faire croire ça. Si tu trouves un livre ou un tutoriel qui dit que c'est possible, cite-le qu'on le brule en place publique immédiatement.
O_o lol![]()
pour ce qui est de cela. xD
Cependant, voilà que je fais malencontrueusement face à un autre problème.
Lorsque j'exécute ce code :
J'obtiens une erreur!?
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8 #include <stdio.h> #include <limits.h> int main(void) { printf("\n%d\n", LLONG_MAX); return 0; }
Le programme écrit :
Pourquoi!?-1
Compilé avec GCC. . .
Serais-ce ma machine qui n'est pas conforme aux standards?!
Merci. Cordialement,
Array
Une erreur de compilation ou un warning ?
Si tu obtiens un erreur, tu ne peux pas exécuter ton programme.
Ensuite, c'est normal que tu n'obtiennes pas la valeur attendue car le formateur %d c'est pour les int, et toi tu lui passes un long long int, il faut mettre %lld (lettre "elle").
Pour afficher un long long, il faut plus puissant qu'un simple %d... En principe, il faut un %lld. (et c'est le cas sur unixoide avec un gcc récent, c'est à dire > 3.0)
Mais sous Windows, même MinGW utilise la bibliothèque standard du C de Windows (msvcrt.dll) qui refuse toute évolution vers le C99 (Politique affichée de Microsoft).
Il faut donc utiliser le format "%I64" à la place de "%lld", ce qui donne,
ou, si on veut être portable :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9 #include <stdio.h> #include <limits.h> int main(void) { printf("%I64d\n", LLONG_MAX); return 0; }
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15 #include <stdio.h> #include <limits.h> #ifdef WIN32 #define LL "I64" #else #define LL "ll" #endif int main(void) { printf("%"LL"d (%"LL"X)\n", LLONG_MAX, LLONG_MAX); return 0; }
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 9223372036854775807 (7FFFFFFFFFFFFFFF) Press ENTER to continue.
o_O Merci Emmannuel. Je t'aime à la folie.![]()
P.S. Si je compile ton code avec GCC. Cela fonctionne parfaitement. Cependant, avec ICC [I = Intel, je suis sûr que tu le sais mais bon...], on me dit :
Envoyé par ICC v10.0.026
Soit tu n'as pas inclus l'en-tête standard limits.h, soit le compilateur d'Intel n'implante pas C99 et type long long int (cela m'étonne...).
Thierry
"The most important thing in the kitchen is the waste paper basket and it needs to be centrally located.", Donald Knuth
"If the only tool you have is a hammer, every problem looks like a nail.", probably Abraham Maslow
FAQ-Python FAQ-C FAQ-C++
+
Ha! En cherchant un peux j'ai trouvé.
ICC supporte le C99, et je l'éxécute toujourss avec /Qstd=c99.
En fait, c'est parce que le compilateur d'Intel utilise les en-têtes (fichiers .h) de Microsoft Visual Studio, et non ses propres fichiers d'en-tête comme GCC.
Ainsi, en cherchamt un peux j'ai trouvé que dans le fichier LIMITS.H de M$ Viual Studio, il n'y a pas de LLONG_MAX/ULLONG_MAX... LLONG_MAX correspont à _I64_MAX & ULLONG_MAX à _UI64_MAX.
Donc, pour résoudre ce problème :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 #if defined(_WIN32) || defined (WIN32) #define LLONG_MAX _i64_MAX #define ULLONG_MAX _UI64_MAX #endif
Partager