Discussion :

[Polychin-elle]

Bonjour a tous.

Je viens de commencer la programmation C++ et nous avons vu le langage binaire ainsi que les types (int float etc...) et leur taille.

L'exercice qui nous a ete donne porte donc sur ca. Malheuresuement je ne comprends pas comment faire.

Montrez la représentation interne binaire des nombres suivants dans les types numériques indiqués. IL se peut que la reponse ne soit pas «représentable ».

ECRIRE 47 et - 47

en char, unsigned char, short, unsigned short, long, unsgned long.

A vrai dire je ne vois pas non plus en quoi l'ecriture binaire devrait differencier si c'est un unsigned ou pas. Et dans le cas ou le type code en 32 bits, on doit vraiment ecrire 32 chiffres? Je suis perdue...

[koala01]

Bonjour a tous.

Je viens de commencer la programmation C++ et nous avons vu le langage binaire ainsi que les types (int float etc...) et leur taille.

L'exercice qui nous a ete donne porte donc sur ca. Malheuresuement je ne comprends pas comment faire.

Montrez la représentation interne binaire des nombres suivants dans les types numériques indiqués. IL se peut que la reponse ne soit pas «représentable ».

ECRIRE 47 et - 47

en char, unsigned char, short, unsigned short, long, unsgned long.

A vrai dire je ne vois pas non plus en quoi l'ecriture binaire devrait differencier si c'est un unsigned ou pas.

Réfléchis peut etre à la signification de unsigned et à ce que cela implique...

Aides toi dans ta réflexion de ce qui se fait dans "la vie de tous les jours".

Tu devrais rapidement arriver à déterminer en quoi l'écriture binaire peut etre différente si tu as affaire à un type signed (qui n'est que l'inverse par défaut de unsigned) ou à un type unsigned

Et dans le cas ou le type code en 32 bits, on doit vraiment ecrire 32 chiffres? Je suis perdue...

Encore une fois, un peu de réflexion devrait te mettre très largement sur la voie...

Tu peux très bien envisager, comme dans la vie de tous les jours, de n'indiquer que les chiffres significatifs : indiquer 1998 et non 0000001998 n'est absolument pas faux

Il est, cependant, largement préférable d'indiquer l'ensemble des bits sur lesquels tu travailles pour la simple et bonne raison qu'une que la valeur binaire suivant 1111 1111 sera différente de la valeur suivant 0000 0000 1111 1111 (tu obtiendras 0 d'un coté et 0000 0001 0000 0000, soit 256 de l'autre).

Ensuite, réfléchis peut etre au fait que si X' est une valeur négative dont X est l'équivalent positif, tu as la formule X + X' = 0 qui sera toujours vraie.

Il en va bien souvent en binaire comme dans la vie de tous les jours, si bien que l'on utilise couramment le principe du complément à deux :
Soit la valeur binaire positive (X) 0010 1111, la valeur binaire négative (X') sera la valeur qui, additionnée à X permettra d'obtenir 0.

Pour ce faire, on commencera par inverser l'ensemble des bits (cela revient à prendre "le complément à 1" ) : 1101 0000, mais comme 0010 111 + 1101 0000 donne... 1111 1111, il faut encore rajouter un pour obtenir 0000 0000 ce qui nous fait bel et bien le complément à 2

Si tu fais le rapprochement entre cette technique du complément à deux et ce que j'ai mis en évidence quelques lignes plus tôt, tu devrais assez rapidement pouvoir déterminer si, oui ou non, il est intéressant d'afficher l'ensemble des bits, principalement pour les valeurs négatives

[Polychin-elle]

Pour le char je sais qu'il code en 8 bits. J'ai donc ecrit 47 pour 8 bits. Ce qui m'a donne:

0 0 0 0 1 0 1 1 1

et -47 : 1 1 1 1 0 1 0 0 0

Maintenant je ne vois toujours pas en quoi le unsigned va changer quelque chose. Et pouir ce qui est du short ou du long je ne sais pas en combien de bits ca code.

[Neckara]

Maintenant je ne vois toujours pas en quoi le unsigned va changer quelque chose.

1 1 1 1 0 1 0 0 0 <=> 0xF8

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
unsigned uchar = 0xF8;
signed schar = 0xF8;
char c= 0xF8;

Maintenant affiche la valeur de uchar et de schar et tu devrais avoir une différence de valeur.
Pour c, c'est indéterminé, un char est un type différent d'un unsigned char et d'un signed char.

Et pouir ce qui est du short ou du long je ne sais pas en combien de bits ca code.

Utilise sizeof(type) pour savoir sa taille en octet / la taille d'un char en octet. Comme un char est toujours codé sur un octet, tu obtiendra donc directement la taille en octet.

[3DArchi]

Salut,

Et pouir ce qui est du short ou du long je ne sais pas en combien de bits ca code.

Et tu as raison car ce n'est pas précisé par le langage. Bien sur il y a des contraintes sur les types, les plages minima qu'ils doivent pouvoir représenter, itout, mais leur taille exacte dépend du compilateur.

Comme un char est toujours codé sur un octet, tu obtiendra donc directement la taille en octet.

sizeof(char)==1, mais char n'est pas forcément sur un octet... cf CHAR_BIT

[koala01]

D'autant plus que, si 47 fait, codé sur 8 bits, 0 0 1 0 1 1 1 1 , -47 ne fais pas 1 1 0 1 0 0 0 0, mais 1 1 0 1 0 0 0 1 (règle du complément à 2)...

Seulement, comme j'ai essayé de te l'expliquer, dans le terme unsigned char, tu as le terme unsigned, qui signifie "non signé".

Cela signifie que le bit de poids fort (le dernier bit sur la gauche en utilisant la notation actuelle) ne représente plus le signe ( - s'il vaut 1, + s'il vaut 0), mais une valeur égale à... 2^7, soit... 128.

Du coup, d'avoir une valeur négative égale à 47, tu te retrouve avec une valeur positive de ...209 vu que la limite basse des valeurs possibles est... 0 (étant donné qu'il n'y a pas moyen de représenter les valeurs négatives avec les types non signés).

Enfin, cette valeur de -47 ne sera pas représentée de la même manière si elle doit être codée sur 8, 16 ou 32 bits, la règle du complément à deux faisant que -47 sur un type signé de 8 bits vaudrait... 209 sur 16 et 32 bits en considérant que les bits supplémentaires (B8 à B15 ou B8 à B31) sont à 0.

[Neckara]

sizeof(char)==1, mais char n'est pas forcément sur un octet... cf CHAR_BIT

En théorie mais en pratique, il ne me semble pas que les char soient stockés sur autre chose qu'un octet sauf dans des cas très rare en embarqués ?

Mais en effet j'aurais mieux fait de dire :
"sizeof(type) renvoit la taille du type/taille d'un char"

[Bousk]

La partie 2 du cursus bas-niveau dont la traduction devrait arriver bientôt donne quelques détails à ce sujet.
En général un char fait 8bits, et c'est le cas général. Les autres valeurs sont des cas particuliers très très spécifiques, voire uniquement à titre privé pour des tests.
Mais on ne devrait jamais travailler sur de tel cas à priori.


Par rapport au sujet, unsigned signifiant "non signé", et donc > 0. Le premier bit ne sert donc plus de bit de signe. Représenter un nombre négatif devient difficile

[koala01]

La partie 2 du cursus bas-niveau dont la traduction devrait arriver bientôt donne quelques détails à ce sujet.
En général un char fait 8bits, et c'est le cas général. Les autres valeurs sont des cas particuliers très très spécifiques, voire uniquement à titre privé pour des tests.
Mais on ne devrait jamais travailler sur de tel cas à priori.


Par rapport au sujet, unsigned signifiant "non signé", et donc > 0. Le premier bit ne sert donc plus de bit de signe. Représenter un nombre négatif devient difficile

En fait, à l'origine, les bytes ne faisaient absolument pas 8 bits...

La plupart des systèmes actuels utilisent maintenant des bytes de 8 bits, mais il reste malgré tout réducteur d'en faire une généralité

[Polychin-elle]

Merci a vous pour vos explications

J'e crois avoir enfin compris le raisonnement!

Si je suis dans le langage C++.

47 en short (16bits) = 0000000000101111
-47 en short (16bits)= 1111111111010000

Maintenant dans le cas du unsigned char (256 max) 47 est representable et reste 000101111 mais -47 ne le sera pas puisqu'il est negatif.

Si on avait pris le chiffre 140,
en char ce ne serait pas representable puisque la vaeur maximale du char est 127 (il me semble) mais dans l'unsigned char on le representerait et cela donnerait 010001100.

Je pense que c'est le raisonnement a avoir. Je me prenais la tete pur rien finalement. Merci encore a vous pour votre aide!