Discussion :

[Speakers]

Bonjour, j'ai quelques questions à poser concernant la compréhension de certains types de donnés:

A) Concernant les données de types ''signed/unsigned''

Si j'ai bien compris ce type de donnés, le type de donnée signed correspond à toutes les valeurs qui peuvent être soit négative soit positive et le type de donnée unsigned n'est pas signé donc correspondra à toutes les valeurs positives. Et si j'ai bien compris ce qui différencie les deux types de données, c'est la représentation décimale des valeurs qui ne sera pas la même puisque les valeurs négatives sont stockés en complément à 2 alors que les valeurs positives non.


QUESTION 1: Dois-je utiliser le mot clef unsigned pour toutes les variables qui resteront positives du début jusqu'à la fin de mon programme? Si ma variable est susceptible d'être négative à un moment donné dans mon programme, je dois indiqué le mot-clef signed, est-ce correct?

QUESTION 2: J'ai cru comprendre qu'il était également possible d'attribuer les mots-clefs ''signed/unsigned'' à un ''char'', je comprends que les caractères sont stockés en ASCII et valent donc des nombre entier, mais comment puis-je savoir que le caractère ''BONJOUR'' est une valeur négative ou positive?

QUESTION 3: J'ai essayé d'attribuer les mots-clefs signed et unsigned à un nombre flottant mais j'obtiens une erreur. La conclusion que j'ai faites est que toutes les valeurs flottantes sont stockés positivement? Est-ce correct?

B) Concernant les données de types ''short/long''

Ici, les mots-clefs sont aussi utiles pour indiquer la représentation décimale à avoir je penses. J'ai constaté que le mot-clef short contenait une plage de valeur comprises entre -32 768 et 32 767 alors que le mot-clef long entre -2 147 483 648 à 2 147 483 647.

QUESTION 4: Dois-je utiliser le mot-clef short pour toutes les valeurs qui durant le programme resteront comprises entre -32 738 et 32 767? (pour les int) et le mot-clef long pour toutes les valeurs qui seront supérieurs à ces valeurs?

----------------------------

QUESTION FINAL: Quel est l’intérêt d'indiquer la représentation décimale que l'on souhaite avoir?

Merci à ceux qui prendront le temps de répondre à mes incompréhensions :p

[koala01]

Salut,

Si j'ai bien compris ce type de donnés, le type de donnée signed correspond à toutes les valeurs qui peuvent être soit négative soit positive et le type de donnée unsigned n'est pas signé donc correspondra à toutes les valeurs positives. Et si j'ai bien compris ce qui différencie les deux types de données, c'est la représentation décimale des valeurs qui ne sera pas la même puisque les valeurs négatives sont stockés en complément à 2 alors que les valeurs positives non.

oui, c'est tout à fait cela...

A noter qu'il y a un bit particulier qui sert à la représentation du signe moins sur les types signés et qui est utilisé pour la représentation de la valeur elle-même pour les types non signé.

C'est ce qui explique que l'intervale est de même taille, et qu'il n'y a que les bornes qui changent (par exemple [-127, 127[ pour signed char et [0,255[ pour unsigned char

QUESTION 1: Dois-je utiliser le mot clef unsigned pour toutes les variables qui resteront positives du début jusqu'à la fin de mon programme? Si ma variable est susceptible d'être négative à un moment donné dans mon programme, je dois indiqué le mot-clef signed, est-ce correct?

C'est toujours une pratique intéressante, en effet... Sauf si, pour une raison ou une autre, tu souhaites pouvoir représenter une "valeur invalide". Il peut alors être utile d'envisager d'utiliser les valeurs signées et de considérer que la valeur -1 (ou n'importe quelle autre valeur négative de ton choix) représente cette "valeur invalide" (*).

(*) en allant plus loin, tu peux tout aussi bien considérer de donner une signification particulière à plusieurs valeurs négatives

QUESTION 2: J'ai cru comprendre qu'il était également possible d'attribuer les mots-clefs ''signed/unsigned'' à un ''char'', je comprends que les caractères sont stockés en ASCII et valent donc des nombre entier,

Tout à fait: la notion de caractère ne fait que donner une signification particulière à la valeur représentée par un byte (par un "octet", pour choisir un terme francais que j'exècre).

mais comment puis-je savoir que le caractère ''BONJOUR'' est une valeur négative ou positive?

A vrai dire, tu t'en fous royalement, car:

• A la base, les caractères ASCII étaient tous (à l'exception d'un seul) codés sur 7 bits, le huitième (celui qui est utilisé comme signe négatif ou comme valeur) étant d'office à 0 sauf pour le caractère "delete" (dont la valeur était 255, soit 0xFF en hexadécimal ou 11111111 en binaire).
• Même si on parle de /*signed*/ char et de unsigned char c'est la valeur binaire non signée qui est prise en compte pour la mise en relation entre la valeur du byte et le glyphe affiché.

Si bien qu'il n'y a que si tu t'intéresse à ton char pour sa valeur numérique que la différence signée Vs non signée aura de l'importance

QUESTION 3: J'ai essayé d'attribuer les mots-clefs signed et unsigned à un nombre flottant mais j'obtiens une erreur. La conclusion que j'ai faites est que toutes les valeurs flottantes sont stockés positivement? Est-ce correct?

Hé non..

Les valeurs réelles sont stockées sous la forme "scientifique": une mantisse (susceptible de contenir un signe négatif) et un exposant (lui-aussi susceptible de contenir un signe négatif)...

B) Concernant les données de types ''short/long''

Ici, les mots-clefs sont aussi utiles pour indiquer la représentation décimale à avoir je penses. J'ai constaté que le mot-clef short contenait une plage de valeur comprises entre -32 768 et 32 767 alors que le mot-clef long entre -2 147 483 648 à 2 147 483 647.

C'est effectivement souvent le cas. Mais attention!!! C++ se contente de dire que sizeof(short) <= sizeof(int) ou, si tu préfère, la taille (exprimée en nombre de bytes) du type short est plus petite ou égale à la taille (toujours exprimée en nombre de bytes) du type int.

Or, la plage de valeur d'un type primitif dépend du nombre de bits (et donc du nombre de bytes) dont il est composé. On peut donc parfaitement envisager de tomber sur des architectures particulières sur lesquelles la plage de valeur associée au type short est la même que celle associée au type int

QUESTION 4: Dois-je utiliser le mot-clef short pour toutes les valeurs qui durant le programme resteront comprises entre -32 738 et 32 767? (pour les int) et le mot-clef long pour toutes les valeurs qui seront supérieurs à ces valeurs?

Ca, c'est la question à €20 000... Car il y a plusieurs aspects à prendre en compte:

Dans l'absolu, on aurait tendance à dire que oui, car cela permet au compilateur de faire des vérifications plus précises (et, le cas échéant, d'émettre des avertissement en cas de risque de dépassement), et que le type short prend -- a priori -- moins de place en mémoire que le type int mais...

Il y a toute une série de considérations qui entre en ligne de compte (*), qui font que, au final, on a souvent intérêt à utiliser le type "le plus adapté à l'architecture" pour laquelle on veut compiler le programme.

(*) parmis lesquelles on peut citer -- entre autres, et de manière loin d'être exhaustive -- le phénomène d'alignement des données effectué par le compilateur et la taille des registres du processeur sur lequel on prévoit de faire tourner l'application)

QUESTION FINAL: Quel est l’intérêt d'indiquer la représentation décimale que l'on souhaite avoir?

Ca, par contre, c'est pas clair du tout : une représentation décimale, c'est d'office une représentation en base 10 : qui permet la représentation de 10 chiffres différents (0,1,2,3,4,5,6,7,8 et 9).

Les autres représentations possible sont

• la base 2 ou binaire: qui permet la représentation de deux chiffres différents (0 et 1)
• la base 8 ou octale : qui permet la représentation de 8 chiffres différents(0,1,2,3,4,5,6 et 7)
• la base 16 ou hexadécimale: qui permet la représentation de 16 chiffres différents (1,2,3,4,5,6,7,8,9,A,B,C,D,E et F)

N'importe quelle valeur peut être représentée dans n'importe quelle base, la conversion de l'une vers l'autre étant *** relativement *** aisée.

L'avantage des notations octales et hexadécimale, étant que les valeurs maximales représentable (7 pour l'octal et F pour l'hexadécimal) sont également représentables en binaire avec "un certain nombre" de bits mis à 1 (111 binaire == 7 == 7 en octal et 1111 en binaire = 17 en octal == F en hexadécimal )

[Bousk]

Si tu t'intéresses d'aussi près à la plage de valeurs d'un entier, tu devrais utiliser des entiers plus précis comme (u)int[8|16|32|64] disponibles dans cstdint.

[Speakers]

Merci pour vos réponses, le topic passe en résolu.

[Luc Hermitte]

Autre différence entre signed et unsigned. Le comportement de u++ est définit pas la norme, ce qui implique que le compilateur peut avoir à dégrader les performances pour garantir de cycler comme il se doit. Le comportement de s++ n'est pas défini: les compilo ont le droit d'optimiser.

Q1, il y a une chasse à unsigned en ce moment chez certains experts. Il y a des problèmes pour avoir un code correct quand on décrémente, et de performances sous certaines conditions

Q2: char n'est ni signé ni non signé, et c'est le type qui va bien pour stocker des caractères. L'ASCII ne couvre que les caractères de 0 à 127 par définition. Au delà, c'est autre chose, et cela dépend de l'encodage courant.
BTW, byte != octet. Un byte peut aussi être constitué de 9 ou 16 bits.
BTW, bis, "BONJOUR", n'est pas un caractère. C'est une chaîne de caractères.

Sinon, j'utilise "unsigned char" quand je décode des trames binaires pour reconstituer une information éclatée sur un ensemble de bits plus ou moins variables. Quand on travaille au niveau bits, être en unsigned est plus propre et plus sûr.

Q4: +1 à std::uint16_t, std::uint_least16_t, std::uint_fast16_t & cie

[koala01]

BTW, byte != octet. Un byte peut aussi être constitué de 9 ou 16 bits.

C'est bien pour cela que j'ai utilisé le terme de byte presque partout, après avoir précisé que j'exécrais le terme d'octet, qui fait -- par définition -- 8bits

Mais je ne voulais pas *** trop *** rentrer dans les détails... Merci de l'avoir fait pour moi