Bof... je te rappelle que toutes les merdouilles de int != void* qu'on voit aujourd'hui correspondent directement a du code ecrit il y a 5 a 10 ans,
Euh... Au beau milieu des années 80 (cela fait plus de 20 ans, donc), on avait déjà des critiques à l'encontre des ces @&*! de programmeurs qui pensaient qu'il « n'y avait au monde que des Vaxen. »
Oui, s'il y a bien une constante en ce bas monde, c'est que les cons, ca ose tout...
In article <epl66b$7ul$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:
Marc Espie écrivit dans news:epi1g5$2h8m$1@biggoron.nerim.net:
Bof... je te rappelle que toutes les merdouilles de int != void* qu'on
voit aujourd'hui correspondent directement a du code ecrit il y a 5 a
10 ans,
Euh... Au beau milieu des années 80 (cela fait plus de 20 ans, donc), on
avait déjà des critiques à l'encontre des ces @&*! de programmeurs qui
pensaient qu'il « n'y avait au monde que des Vaxen. »
Oui, s'il y a bien une constante en ce bas monde, c'est que les cons, ca ose
tout...
Bof... je te rappelle que toutes les merdouilles de int != void* qu'on voit aujourd'hui correspondent directement a du code ecrit il y a 5 a 10 ans,
Euh... Au beau milieu des années 80 (cela fait plus de 20 ans, donc), on avait déjà des critiques à l'encontre des ces @&*! de programmeurs qui pensaient qu'il « n'y avait au monde que des Vaxen. »
Oui, s'il y a bien une constante en ce bas monde, c'est que les cons, ca ose tout...
"Debugging? Klingons do not debug! Our software does not coddle the weak."
Vincent Lefevre
Dans l'article <epl5v9$71p$, Antoine Leca écrit:
Le gros intérêt de uint8_t[], c'est que tu est sûr (à partir du moment où cela compile, avec un compilo "ANSI") que cela sera promu en int (signé); avec ton unsigned char, tu n'as plus cette garantie ; et ce peut être une gêne pour ton algorithme, qui va devenir plus complexe, moins clair (même s'il sera plus «universel»).
Ça depend du type de l'implémentation. Si on a besoin de la bibliothèque standard, alors on sait qu'un unsigned char est représentable dans un int.
Dans l'article <epl5v9$71p$2@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> écrit:
Le gros intérêt de uint8_t[], c'est que tu est sûr (à partir du moment où
cela compile, avec un compilo "ANSI") que cela sera promu en int (signé);
avec ton unsigned char, tu n'as plus cette garantie ; et ce peut être une
gêne pour ton algorithme, qui va devenir plus complexe, moins clair (même
s'il sera plus «universel»).
Ça depend du type de l'implémentation. Si on a besoin de la
bibliothèque standard, alors on sait qu'un unsigned char est
représentable dans un int.
Le gros intérêt de uint8_t[], c'est que tu est sûr (à partir du moment où cela compile, avec un compilo "ANSI") que cela sera promu en int (signé); avec ton unsigned char, tu n'as plus cette garantie ; et ce peut être une gêne pour ton algorithme, qui va devenir plus complexe, moins clair (même s'il sera plus «universel»).
Ça depend du type de l'implémentation. Si on a besoin de la bibliothèque standard, alors on sait qu'un unsigned char est représentable dans un int.
SUBTILISER. v. tr. Rendre subtil, volatiliser. /Subtiliser une substance/. Il est vieux. Il signifie encore, figurément et familièrement, Faire disparaître, dérober, voler. /On lui a subtilisé sa bourse, son argent/. [... + autre emploi, intr.]
/in/ Dictionnaire de l'Académie française, 8e éd., Paris, 1932-35 (http://atilf.atilf.fr/academie.htm)
J'avais utilisé le deuxième emploi. Désolé pour la familiarité, par conséquent.
Antoine
Pascal Bourguignon écrivit dans
news:87k5z5o9zl.fsf@thalassa.informatimago.com:
"Antoine Leca" <root@localhost.invalid> writes:
car il subtilise le bit de poids de
"sous-utilise" en français. Merci.
?
SUBTILISER. v. tr. Rendre subtil, volatiliser. /Subtiliser une substance/.
Il est vieux.
Il signifie encore, figurément et familièrement, Faire disparaître, dérober,
voler. /On lui a subtilisé sa bourse, son argent/. [... + autre emploi,
intr.]
/in/ Dictionnaire de l'Académie française, 8e éd., Paris, 1932-35
(http://atilf.atilf.fr/academie.htm)
J'avais utilisé le deuxième emploi. Désolé pour la familiarité, par
conséquent.
SUBTILISER. v. tr. Rendre subtil, volatiliser. /Subtiliser une substance/. Il est vieux. Il signifie encore, figurément et familièrement, Faire disparaître, dérober, voler. /On lui a subtilisé sa bourse, son argent/. [... + autre emploi, intr.]
/in/ Dictionnaire de l'Académie française, 8e éd., Paris, 1932-35 (http://atilf.atilf.fr/academie.htm)
J'avais utilisé le deuxième emploi. Désolé pour la familiarité, par conséquent.
Antoine
Pascal Bourguignon
"Antoine Leca" writes:
Pascal Bourguignon écrivit dans news::
"Antoine Leca" writes:
car il subtilise le bit de poids de
"sous-utilise" en français. Merci.
?
SUBTILISER. v. tr. Rendre subtil, volatiliser. /Subtiliser une substance/. Il est vieux. Il signifie encore, figurément et familièrement, Faire disparaître, dérober, voler. /On lui a subtilisé sa bourse, son argent/. [... + autre emploi, intr.]
/in/ Dictionnaire de l'Académie française, 8e éd., Paris, 1932-35 (http://atilf.atilf.fr/academie.htm)
J'avais utilisé le deuxième emploi. Désolé pour la familiarité, par conséquent.
This universe shipped by weight, not volume. Some expansion may have occurred during shipment.
"Antoine Leca" <root@localhost.invalid> writes:
Pascal Bourguignon écrivit dans
news:87k5z5o9zl.fsf@thalassa.informatimago.com:
"Antoine Leca" <root@localhost.invalid> writes:
car il subtilise le bit de poids de
"sous-utilise" en français. Merci.
?
SUBTILISER. v. tr. Rendre subtil, volatiliser. /Subtiliser une substance/.
Il est vieux.
Il signifie encore, figurément et familièrement, Faire disparaître, dérober,
voler. /On lui a subtilisé sa bourse, son argent/. [... + autre emploi,
intr.]
/in/ Dictionnaire de l'Académie française, 8e éd., Paris, 1932-35
(http://atilf.atilf.fr/academie.htm)
J'avais utilisé le deuxième emploi. Désolé pour la familiarité, par
conséquent.
SUBTILISER. v. tr. Rendre subtil, volatiliser. /Subtiliser une substance/. Il est vieux. Il signifie encore, figurément et familièrement, Faire disparaître, dérober, voler. /On lui a subtilisé sa bourse, son argent/. [... + autre emploi, intr.]
/in/ Dictionnaire de l'Académie française, 8e éd., Paris, 1932-35 (http://atilf.atilf.fr/academie.htm)
J'avais utilisé le deuxième emploi. Désolé pour la familiarité, par conséquent.
This universe shipped by weight, not volume. Some expansion may have occurred during shipment.
Jean Pierre Daviau
Sur un Pentium (toujours pour l'exemple), un char sera typiquement signé et ira de -128 à +127 (le -128 est un plus par rapport à la norme qui demande juste -127). Sur un DSP 32 bits, un "unsigned char" ira de 0 à 2147483647.
Où on trouve ce genre d'information?
Pour Intel(R) Celeron (R) CPU 2.00 GHz Processor Radeon7000 0x5159 agp
par exemple. Sur leur site? Dans le 'manual'
Sur un Pentium (toujours pour l'exemple), un char sera
typiquement signé et
ira de -128 à +127 (le -128 est un plus par rapport à la norme
qui demande
juste -127). Sur un DSP 32 bits, un "unsigned char" ira de 0 à
2147483647.
Où on trouve ce genre d'information?
Pour
Intel(R) Celeron (R) CPU 2.00 GHz
Processor Radeon7000 0x5159 agp
Sur un Pentium (toujours pour l'exemple), un char sera typiquement signé et ira de -128 à +127 (le -128 est un plus par rapport à la norme qui demande juste -127). Sur un DSP 32 bits, un "unsigned char" ira de 0 à 2147483647.
Où on trouve ce genre d'information?
Pour Intel(R) Celeron (R) CPU 2.00 GHz Processor Radeon7000 0x5159 agp
par exemple. Sur leur site? Dans le 'manual'
espie
In article <qFJvh.69489$, Jean Pierre Daviau wrote:
Sur un Pentium (toujours pour l'exemple), un char sera typiquement signé et ira de -128 à +127 (le -128 est un plus par rapport à la norme qui demande juste -127). Sur un DSP 32 bits, un "unsigned char" ira de 0 à 2147483647.
Où on trouve ce genre d'information?
Pour Intel(R) Celeron (R) CPU 2.00 GHz Processor Radeon7000 0x5159 agp
par exemple. Sur leur site? Dans le 'manual'
Dans la documentation du compilateur, normalement.
Ces caracteristiques font partie des details d'implementation du langage C qui doivent etre specifies quelque part.
Si tu preferes, ces details sont assez directement influences par le processeur, pour des raisons d'efficacite, mais il n'y a pas toujours de raison reelle de faire un choix plutot qu'un autre.
L'auteur du message que tu cites a ete imprecis: les implementations habituelles de C sur un micro-processeur intel vont utiliser des char de -128 a 127, mais il n'y a pas d'obligation. Par exemple, gcc possede une option qui permet de changer de conventions pour les caracteres.
(sur les DSP ou les char font plus de 8 bits, en general, c'est parce que le DSP en question ne possede pas de type natif tout petit, et que recuperer des valeurs sur 8 bits serait beaucoup trop couteux en termes d'instructions machines).
Apres, evidemment, ca peut poser des problemes. Par exemple, si le code genere par le compilateur n'est plus compatible avec une grosse partie du systeme (notion d'ABI du systeme d'exploitation). Voire meme si le vendeur du compilateur ne fournit pas de bibliotheque standard compatible avec ces options.
Pour ces aspects-la, on peut trouver les ABI (application binary interfaces) de divers systemes d'exploitation sur le web, voire de certains processeurs (plus ou moins obligatoires selon les constructeurs). Par exemple, l'architecture powerpc dispose d'une ABI relativement standardisee, et la plupart des compilateurs s'y conforment.
Ceci pour eviter une erreur courante: les types standards du C sont dependants d'une implementation, donc d'un processeur, d'un compilateur, d'une bibliotheque standard, d'une interface avec le reste du systeme... Il n'y a pas de raison profonde pour qu'un element du puzzle controle de facon certaine les choix a faire, et en pratique, tous ces elements sont parfois a prendre en compte, et peuvent poser de subtils problemes...
In article <qFJvh.69489$hn6.514633@weber.videotron.net>,
Jean Pierre Daviau <Once@WasEno.ugh> wrote:
Sur un Pentium (toujours pour l'exemple), un char sera
typiquement signé et
ira de -128 à +127 (le -128 est un plus par rapport à la norme
qui demande
juste -127). Sur un DSP 32 bits, un "unsigned char" ira de 0 à
2147483647.
Où on trouve ce genre d'information?
Pour
Intel(R) Celeron (R) CPU 2.00 GHz
Processor Radeon7000 0x5159 agp
par exemple. Sur leur site? Dans le 'manual'
Dans la documentation du compilateur, normalement.
Ces caracteristiques font partie des details d'implementation du langage C
qui doivent etre specifies quelque part.
Si tu preferes, ces details sont assez directement influences par le
processeur, pour des raisons d'efficacite, mais il n'y a pas toujours
de raison reelle de faire un choix plutot qu'un autre.
L'auteur du message que tu cites a ete imprecis: les implementations
habituelles de C sur un micro-processeur intel vont utiliser des char
de -128 a 127, mais il n'y a pas d'obligation. Par exemple, gcc possede
une option qui permet de changer de conventions pour les caracteres.
(sur les DSP ou les char font plus de 8 bits, en general, c'est parce que
le DSP en question ne possede pas de type natif tout petit, et que recuperer
des valeurs sur 8 bits serait beaucoup trop couteux en termes d'instructions
machines).
Apres, evidemment, ca peut poser des problemes. Par exemple, si le code
genere par le compilateur n'est plus compatible avec une grosse partie
du systeme (notion d'ABI du systeme d'exploitation). Voire meme si le
vendeur du compilateur ne fournit pas de bibliotheque standard compatible
avec ces options.
Pour ces aspects-la, on peut trouver les ABI (application binary interfaces)
de divers systemes d'exploitation sur le web, voire de certains
processeurs (plus ou moins obligatoires selon les constructeurs).
Par exemple, l'architecture powerpc dispose d'une ABI relativement
standardisee, et la plupart des compilateurs s'y conforment.
Ceci pour eviter une erreur courante: les types standards du C
sont dependants d'une implementation, donc d'un processeur, d'un compilateur,
d'une bibliotheque standard, d'une interface avec le reste du systeme...
Il n'y a pas de raison profonde pour qu'un element du puzzle controle
de facon certaine les choix a faire, et en pratique, tous ces elements
sont parfois a prendre en compte, et peuvent poser de subtils problemes...
In article <qFJvh.69489$, Jean Pierre Daviau wrote:
Sur un Pentium (toujours pour l'exemple), un char sera typiquement signé et ira de -128 à +127 (le -128 est un plus par rapport à la norme qui demande juste -127). Sur un DSP 32 bits, un "unsigned char" ira de 0 à 2147483647.
Où on trouve ce genre d'information?
Pour Intel(R) Celeron (R) CPU 2.00 GHz Processor Radeon7000 0x5159 agp
par exemple. Sur leur site? Dans le 'manual'
Dans la documentation du compilateur, normalement.
Ces caracteristiques font partie des details d'implementation du langage C qui doivent etre specifies quelque part.
Si tu preferes, ces details sont assez directement influences par le processeur, pour des raisons d'efficacite, mais il n'y a pas toujours de raison reelle de faire un choix plutot qu'un autre.
L'auteur du message que tu cites a ete imprecis: les implementations habituelles de C sur un micro-processeur intel vont utiliser des char de -128 a 127, mais il n'y a pas d'obligation. Par exemple, gcc possede une option qui permet de changer de conventions pour les caracteres.
(sur les DSP ou les char font plus de 8 bits, en general, c'est parce que le DSP en question ne possede pas de type natif tout petit, et que recuperer des valeurs sur 8 bits serait beaucoup trop couteux en termes d'instructions machines).
Apres, evidemment, ca peut poser des problemes. Par exemple, si le code genere par le compilateur n'est plus compatible avec une grosse partie du systeme (notion d'ABI du systeme d'exploitation). Voire meme si le vendeur du compilateur ne fournit pas de bibliotheque standard compatible avec ces options.
Pour ces aspects-la, on peut trouver les ABI (application binary interfaces) de divers systemes d'exploitation sur le web, voire de certains processeurs (plus ou moins obligatoires selon les constructeurs). Par exemple, l'architecture powerpc dispose d'une ABI relativement standardisee, et la plupart des compilateurs s'y conforment.
Ceci pour eviter une erreur courante: les types standards du C sont dependants d'une implementation, donc d'un processeur, d'un compilateur, d'une bibliotheque standard, d'une interface avec le reste du systeme... Il n'y a pas de raison profonde pour qu'un element du puzzle controle de facon certaine les choix a faire, et en pratique, tous ces elements sont parfois a prendre en compte, et peuvent poser de subtils problemes...
Antoine Leca
Jean Pierre Daviau écrivit dans news:qFJvh.69489$:
Sur un Pentium (toujours pour l'exemple), un char sera typiquement signé et
En passant : ceci est tout sauf une évidence. On fera mieux de vérifier au cas par cas. Un bon programmeur pourrait se munir d'un compilateur (même médiocre) ayant une option à ce niveau-là, et tester son programme dans les deux cas. Juste pour voir.
ira de -128 à +127 (le -128 est un plus par rapport à la norme qui demande juste -127). Sur un DSP 32 bits, un "unsigned char" ira de 0 à 2147483647.
Où on trouve ce genre d'information?
En plus de tout ce que dit Marc dans son riche message, il y a plein d'informations, quoique parfois codées, dans l'entête <limits.h>.
En l'occurence, les informations se trouvent derrière les constantes CHAR_MIN et CHAR_MAX pour les char, et 0 et UCHAR_MAX pour les unsigned char. Évidemment, il y a aussi SCHAR_MIN et SCHAR_MAX, et une pagaille d'autres pour les autres types entiers.
Pour la manipulation des nombres en virgule flottante, c'est l'entête <float.h> qu'il faut utiliser, et là c'est encore pire, il y en a trop (àmha : car cela rend les programmes portables, qui sont obligés d'y faire référence, lourds et difficiles à comprendre). En fait, une fois que l'on maîtrise l'ensemble des constantes et leurs significations, on doit être un dieu de la programmation en virgule flottante. Mais ce n'est pas mon cas.
Antoine
Jean Pierre Daviau écrivit dans
news:qFJvh.69489$hn6.514633@weber.videotron.net:
Sur un Pentium (toujours pour l'exemple), un char sera
typiquement signé et
En passant : ceci est tout sauf une évidence. On fera mieux de vérifier au
cas par cas. Un bon programmeur pourrait se munir d'un compilateur (même
médiocre) ayant une option à ce niveau-là, et tester son programme dans les
deux cas.
Juste pour voir.
ira de -128 à +127 (le -128 est un plus par rapport à la norme
qui demande
juste -127). Sur un DSP 32 bits, un "unsigned char" ira de 0 à
2147483647.
Où on trouve ce genre d'information?
En plus de tout ce que dit Marc dans son riche message, il y a plein
d'informations, quoique parfois codées, dans l'entête <limits.h>.
En l'occurence, les informations se trouvent derrière les constantes
CHAR_MIN et CHAR_MAX pour les char, et 0 et UCHAR_MAX pour les unsigned
char. Évidemment, il y a aussi SCHAR_MIN et SCHAR_MAX, et une pagaille
d'autres pour les autres types entiers.
Pour la manipulation des nombres en virgule flottante, c'est l'entête
<float.h> qu'il faut utiliser, et là c'est encore pire, il y en a trop (àmha
: car cela rend les programmes portables, qui sont obligés d'y faire
référence, lourds et difficiles à comprendre).
En fait, une fois que l'on maîtrise l'ensemble des constantes et leurs
significations, on doit être un dieu de la programmation en virgule
flottante.
Mais ce n'est pas mon cas.
Jean Pierre Daviau écrivit dans news:qFJvh.69489$:
Sur un Pentium (toujours pour l'exemple), un char sera typiquement signé et
En passant : ceci est tout sauf une évidence. On fera mieux de vérifier au cas par cas. Un bon programmeur pourrait se munir d'un compilateur (même médiocre) ayant une option à ce niveau-là, et tester son programme dans les deux cas. Juste pour voir.
ira de -128 à +127 (le -128 est un plus par rapport à la norme qui demande juste -127). Sur un DSP 32 bits, un "unsigned char" ira de 0 à 2147483647.
Où on trouve ce genre d'information?
En plus de tout ce que dit Marc dans son riche message, il y a plein d'informations, quoique parfois codées, dans l'entête <limits.h>.
En l'occurence, les informations se trouvent derrière les constantes CHAR_MIN et CHAR_MAX pour les char, et 0 et UCHAR_MAX pour les unsigned char. Évidemment, il y a aussi SCHAR_MIN et SCHAR_MAX, et une pagaille d'autres pour les autres types entiers.
Pour la manipulation des nombres en virgule flottante, c'est l'entête <float.h> qu'il faut utiliser, et là c'est encore pire, il y en a trop (àmha : car cela rend les programmes portables, qui sont obligés d'y faire référence, lourds et difficiles à comprendre). En fait, une fois que l'on maîtrise l'ensemble des constantes et leurs significations, on doit être un dieu de la programmation en virgule flottante. Mais ce n'est pas mon cas.
