Output

Le
Guillaume GOURDIN
Bonjour à tous,

j'ai un problème, le code suivat :

uint8_t data1, data2;
cout << "0x" << hex << setw(4) << setfill('0') << data1 << "=";
cout << "0x" << hex << setw(2) << setfill('0') << data2 << endl;

me sort l'output suivant :

0x00aa=0x0

alors que je m'attendrais (et que je voudrais) quelque chose du genre:

0x00aa=0x00

Vous avez des idées?
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jean-Marc Bourguet
Le #1252994
Guillaume GOURDIN
Bonjour à tous,

j'ai un problème, le code suivat :

uint8_t data1, data2;
cout << "0x" << hex << setw(4) << setfill('0') << data1 << "=";
cout << "0x" << hex << setw(2) << setfill('0') << data2 << endl;

me sort l'output suivant :

0x00aa=0x0

alors que je m'attendrais (et que je voudrais) quelque chose du genre:

0x00aa=0x00

Vous avez des idées?


Ce qui me surprend, c'est la partie aa. uint8_t est vraissemblablement un
typedef sur unsigned char et donc data1 et data2 devraient etre affiche
comme des caracteres, si data2 est , c'est pas trop etonnant que tu ne le
voie pas mais tu devrais etre capable de le verifier (piper dans od, sortir
vers un fichier et regarder avec un editeur hexa,...)

Essaie
cout << "0x" << hex << setw(4) << setfill('0') << unsigned(data1) << "=";
cout << "0x" << hex << setw(2) << setfill('0') << unsigned(data2) << endl;

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Michel Decima
Le #1254788
Guillaume GOURDIN
Bonjour à tous,

j'ai un problème, le code suivat :

uint8_t data1, data2;
cout << "0x" << hex << setw(4) << setfill('0') << data1 << "=";
cout << "0x" << hex << setw(2) << setfill('0') << data2 << endl;

me sort l'output suivant :

0x00aa=0x0

alors que je m'attendrais (et que je voudrais) quelque chose du genre:

0x00aa=0x00

Vous avez des idées?


Ce qui me surprend, c'est la partie aa. uint8_t est vraissemblablement un
typedef sur unsigned char et donc data1 et data2 devraient etre affiche
comme des caracteres, si data2 est , c'est pas trop etonnant que tu ne le
voie pas mais tu devrais etre capable de le verifier (piper dans od, sortir
vers un fichier et regarder avec un editeur hexa,...)


Et en plus, le resultat doit etre indefini, vu que data1 et data2 sont
utilisés avant leur initialisation. On en a parlé ici il n'y a pas si
longtemps ;)


Essaie
cout << "0x" << hex << setw(4) << setfill('0') << unsigned(data1) << "=";
cout << "0x" << hex << setw(2) << setfill('0') << unsigned(data2) << endl;


Ca donne bien le resultat attendu (avec des variables correctement
initialisees). A la premiere lecture, j'ai trouve etrange l'usage
explicite du prefixe "0x", parce qu'on peut l'obtenir avec le
manipulateur showbase (il faut aussi internal pour le remplissage).
On devrait donc obtenir le resultat comme ceci :

uint8_t data1 = 0xaa , data2 = 0x0 ;
cout << setw(6) << setfill('0')
<< hex << showbase << internal << unsigned(data1) << "=";
cout << setw(4) << setfill('0')
<< hex << showbase << unsigned(data2) << endl ;

Et la j'obtient:

0x00aa00

A ma grande surprise, showbase n'ajoute pas le prefixe de base pour
a valeur 0 ( il faut dire que ca ne sert a rien vu que 0 est commun
a toutes les bases ). Jusqu'a present je pensais que le prefixe etait
ajouté systematiquement, parce que je n'etait jamais tombé sur le
cas particulier de 0, ni vu dans aucune doc qu'il y avait un
comportement special.

Avec printf, le comportement est identique :

printf( "%#06x=%#04x", unsigned(data1), unsigned(data2) ) ;

0x00aa00

La, c'est quand meme plus clair, parce que le man printf(3) me
dit que pour le caractere #, on a

"For x and X conversions, a non-zero result has the string
0x (or 0X for X conversions) prepended to it."

Les deux langages on le meme comportement, au fond, c'est pratique,
mais est-ce que c'est standard ?


Gabriel Dos Reis
Le #1256581
Michel Decima
| > Guillaume GOURDIN | >
| >> Bonjour à tous,
| >>
| >> j'ai un problème, le code suivat :
| >>
| >> uint8_t data1, data2;
| >> cout << "0x" << hex << setw(4) << setfill('0') << data1 << "=";
| >> cout << "0x" << hex << setw(2) << setfill('0') << data2 << endl;
| >>
| >> me sort l'output suivant :
| >>
| >> 0x00aa=0x0
| >>
| >> alors que je m'attendrais (et que je voudrais) quelque chose du genre:
| >>
| >> 0x00aa=0x00
| >>
| >> Vous avez des idées?
| > Ce qui me surprend, c'est la partie aa. uint8_t est
| > vraissemblablement un
| > typedef sur unsigned char et donc data1 et data2 devraient etre affiche
| > comme des caracteres, si data2 est , c'est pas trop etonnant que tu n e le
| > voie pas mais tu devrais etre capable de le verifier (piper dans od, so rtir
| > vers un fichier et regarder avec un editeur hexa,...)
|
| Et en plus, le resultat doit etre indefini, vu que data1 et data2 sont
| utilisés avant leur initialisation. On en a parlé ici il n'y a pas si
| longtemps ;)

sauf si uint8_t est un unsigned char :-)

-- Gaby
Michel Decima
Le #1256580
Michel Decima
| > Guillaume GOURDIN | >
| >> Bonjour à tous,
| >>
| >> j'ai un problème, le code suivat :
| >>
| >> uint8_t data1, data2;
| >> cout << "0x" << hex << setw(4) << setfill('0') << data1 << "=";
| >> cout << "0x" << hex << setw(2) << setfill('0') << data2 << endl;

| Et en plus, le resultat doit etre indefini, vu que data1 et data2 sont
| utilisés avant leur initialisation. On en a parlé ici il n'y a pas si
| longtemps ;)

sauf si uint8_t est un unsigned char :-)


Mmmh. parce que unsigned char ne peut pas avoir de 'trap value' ?

Sylvain
Le #1257183
Michel Decima wrote on 07/03/2008 21:21:

sauf si uint8_t est un unsigned char :-)


Mmmh. parce que unsigned char ne peut pas avoir de 'trap value' ?


voire parce qu'un type utilisateur influencerait le contenu mémoire ?

Sylvain.


James Kanze
Le #1257182
On 7 mar, 21:27, Sylvain
Michel Decima wrote on 07/03/2008 21:21:


sauf si uint8_t est un unsigned char :-)


Mmmh. parce que unsigned char ne peut pas avoir de 'trap value' ?


voire parce qu'un type utilisateur influencerait le contenu mémoire ?


Le type influence bien comment on y accède.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34



James Kanze
Le #1323307
On 7 mar, 14:47, Michel Decima
Essaie
cout << "0x" << hex << setw(4) << setfill('0') << unsigned(data1) << "=";
cout << "0x" << hex << setw(2) << setfill('0') << unsigned(data2) << endl;


Ca donne bien le resultat attendu (avec des variables
correctement initialisees). A la premiere lecture, j'ai trouve
etrange l'usage explicite du prefixe "0x", parce qu'on peut
l'obtenir avec le manipulateur showbase (il faut aussi
internal pour le remplissage). On devrait donc obtenir le
resultat comme ceci :

uint8_t data1 = 0xaa , data2 = 0x0 ;
cout << setw(6) << setfill('0')
<< hex << showbase << internal << unsigned(data1) << "=";
cout << setw(4) << setfill('0')
<< hex << showbase << unsigned(data2) << endl ;

Et la j'obtient:

0x00aa00

A ma grande surprise, showbase n'ajoute pas le prefixe de base pour
a valeur 0 ( il faut dire que ca ne sert a rien vu que 0 est commun
a toutes les bases ). Jusqu'a present je pensais que le prefixe etait
ajouté systematiquement, parce que je n'etait jamais tombé sur le
cas particulier de 0, ni vu dans aucune doc qu'il y avait un
comportement special.

Avec printf, le comportement est identique :

printf( "%#06x=%#04x", unsigned(data1), unsigned(data2) ) ;

0x00aa00

La, c'est quand meme plus clair, parce que le man printf(3) me
dit que pour le caractere #, on a

"For x and X conversions, a non-zero result has the string
0x (or 0X for X conversions) prepended to it."

Les deux langages on le meme comportement, au fond, c'est pratique,
mais est-ce que c'est standard ?


Oui:-(. J'ai rencontré le même problème, il y a peu. Je l'ai
résolu en sortant le "0x" explicitement. (À vrai dire, ça
m'arrangeait, parce que je voulais l'x dans "0x" minuscule, mais
les chiffres hex majuscule.)

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


Gabriel Dos Reis
Le #1332504
Michel Decima
| > Michel Decima | > | > Guillaume GOURDIN | > | >
| > | >> Bonjour à tous,
| > | >>
| > | >> j'ai un problème, le code suivat :
| > | >>
| > | >> uint8_t data1, data2;
| > | >> cout << "0x" << hex << setw(4) << setfill('0') << data1 << "= ";
| > | >> cout << "0x" << hex << setw(2) << setfill('0') << data2 << endl;
|
| > | Et en plus, le resultat doit etre indefini, vu que data1 et data2 sont
| > | utilisés avant leur initialisation. On en a parlé ici il n' y a pas si
| > | longtemps ;)
| > sauf si uint8_t est un unsigned char :-)
|
| Mmmh. parce que unsigned char ne peut pas avoir de 'trap value' ?

Oui, c'est explicitement requis par la norme.

-- Gaby
Sylvain
Le #1392894
James Kanze wrote on 07/03/2008 22:01:

Le type influence bien comment on y accède.


c'est en substance tout à fait contradictoire avec tes positions
du fil précédent.

Sylvain.

James Kanze
Le #1398700
On 8 mar, 23:40, Sylvain
James Kanze wrote on 07/03/2008 22:01:
Le type influence bien comment on y accède.


c'est en substance tout à fait contradictoire avec tes
positions du fil précédent.


Explique, si te plais. Je ne vois pas comment le type ne
pourrait pas influencer comment on accède aux objets---quand
j'accède à travers un lvalue de type char, par exemple, je
n'accède qu'aux huit bits, tandis qu'avec int... Et je suis
certain de ne jamais avoir dit le contraire.

La norme guarantee qu'un accès à un unsigned char fonctionne.
Même si l'unsigned char n'a jamais été initialisé (mais
évidemment, la valeur que tu vois n'est pas déterminé dans ce
cas-là). La norme ne fait cette garantie pour aucune autre type.
Et il existe bien des architectures, même aujourd'hui, où l'int
contient un bit de tag, positionné implicitement je ne sais pas
trop comment, et où l'accès à un int non initialisé risque de
provoquer un trap hardware (ce qui résumerait en un core dump
sur les systèmes dont je me sers).

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


Publicité
Poster une réponse
Anonyme