Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Equivalent de printf("%#.2X", 2) avec les streams

14 réponses
Avatar
adebaene
Tout est dans le titre...

printf("%#.2X", 2) affiche "0x02" (avec un 0 =E0 gauche pour afficher 2
caract=E8res).

Quel est l'=E9quivalent avec les flux ??
cout<<std::hex<<std::showbase<<?????<<2<<endl;

Que mettre =E0 la place de ????? Ni setw ni setposition ne donnent le
r=E9sultat d=E9sir=E9....
J'ai l'impression que les flux ne permettent pas de controler la
largeur minimale d'afficahge d'un entier. J'ai loup=E9 quelque chose?

Arnaud

10 réponses

1 2
Avatar
xavier
a dit le 16/03/2005 15:39:
printf("%#.2X", 2) affiche "0x02" (avec un 0 à gauche pour afficher 2
caractères).

Quel est l'équivalent avec les flux ??


! #include <iostream>
! #include <iomanip>
!
! using namespace std;
!
! int main() {
! cout << internal << hex << showbase << setfill('0') << setw(4) <<
! 2 << endl;
! }

xavier

Avatar
adebaene
xavier wrote:
a dit le 16/03/2005 15:39:
printf("%#.2X", 2) affiche "0x02" (avec un 0 à gauche pour
afficher 2


caractères).

Quel est l'équivalent avec les flux ??


! #include <iostream>
! #include <iomanip>
!
! using namespace std;
!
! int main() {
! cout << internal << hex << showbase << setfill('0') << setw(4) <<


! 2 << endl;
! }


Merci! On dira ce qu'on veut, il manque quand même quelques
manipulateurs pour avoir un comportement un peu plus "naturel"...

Question annexe : est-ce quelqu'un a une référence *claire* (ou alors
une explication de la logique sous-jacente) pour savoir quels flags de
formattage/manipulateurs sont persistents (comprendre, quels operateurs
s'appliquent uniquement à la prochaine sortie et lesquels restent
actifs jusqu'à nouvel ordre)?

Arnaud


Avatar
kanze
wrote:
xavier wrote:
a dit le 16/03/2005 15:39:
printf("%#.2X", 2) affiche "0x02" (avec un 0 à gauche pour
afficher 2 caractères).

Quel est l'équivalent avec les flux ??


! #include <iostream>
! #include <iomanip>

! using namespace std;

! int main() {
! cout << internal << hex << showbase << setfill('0') << setw(4)
<<



! 2 << endl;
! }


Merci! On dira ce qu'on veut, il manque quand même quelques
manipulateurs pour avoir un comportement un peu plus
"naturel"...


Les manipulateurs de la norme sont les manipulateurs de base,
dont on se sert pour créer ses propres manipulateurs. Donc, dans
une application où on a besoin d'afficher avec ce format, on
créera un manipulateur qui le fait, avec le nom qui convient.

Question annexe : est-ce quelqu'un a une référence *claire*
(ou alors une explication de la logique sous-jacente) pour
savoir quels flags de formattage/manipulateurs sont
persistents (comprendre, quels operateurs s'appliquent
uniquement à la prochaine sortie et lesquels restent actifs
jusqu'à nouvel ordre)?


Là, c'est simple. Tous les flags, la précision et le fill sont
persistents. Le seul élément de formattage qui ne l'est pas,
c'est la largueur.

Là aussi, il est fréquent de s'arranger à mémoriser l'état de
formattage dans le manipulateur, et de le restaurer dans le
destructeur du manipulateur.

--
James Kanze GABI Software
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



Avatar
adebaene
wrote:
Question annexe : est-ce quelqu'un a une référence *claire*
(ou alors une explication de la logique sous-jacente) pour
savoir quels flags de formattage/manipulateurs sont
persistents (comprendre, quels operateurs s'appliquent
uniquement à la prochaine sortie et lesquels restent actifs
jusqu'à nouvel ordre)?


Là, c'est simple. Tous les flags, la précision et le fill sont
persistents. Le seul élément de formattage qui ne l'est pas,
c'est la largueur.


D'où la question suivante : *Pourquoi* avoir fait un cas particulier
pour la largeur????

Là aussi, il est fréquent de s'arranger à mémoriser l'état de
formattage dans le manipulateur, et de le restaurer dans le
destructeur du manipulateur.
Merci des infos.


Arnaud


Avatar
Michel Michaud
Dans le message ,
D'où la question suivante : *Pourquoi* avoir fait un cas particulier
pour la largeur????


J'imagine qu'on peut trouver plusieurs raisons, mais essaie simplement
de faire la moindre écriture complexe sans... Contrairement aux autres
manipulateurs, celui-là a une conséquence sur chaque élément écrit.

À l'inverse, suppose que fixed et setprecision ne soient pas
persistants... (bah, ça ne serait pas si mal, si c'était setp au
lieu de setprecision :-)

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

Avatar
kanze
wrote:
wrote:
Question annexe : est-ce quelqu'un a une référence
*claire* (ou alors une explication de la logique
sous-jacente) pour savoir quels flags de
formattage/manipulateurs sont persistents (comprendre,
quels operateurs s'appliquent uniquement à la prochaine
sortie et lesquels restent actifs jusqu'à nouvel ordre)?


Là, c'est simple. Tous les flags, la précision et le fill
sont persistents. Le seul élément de formattage qui ne l'est
pas, c'est la largueur.


D'où la question suivante : *Pourquoi* avoir fait un cas
particulier pour la largeur????


Bonne question. Je suppose que c'est parce que la largeur varie
plus souvent que les autres, mais ce n'est qu'une supposition.
Personnellement, j'aurais fait qu'ils réprenent tous leur valeur
par défaut dans le déstructeur du sentry ; actuellement, c'est
au charge de l'opérateur << de remettre la largeur à zéro. Et
ces histoires d'un état qui traine ne sont pas très propres.

--
James Kanze GABI Software
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



Avatar
Arnaud Debaene
Michel Michaud wrote:

J'imagine qu'on peut trouver plusieurs raisons, mais essaie simplement
de faire la moindre écriture complexe sans... Contrairement aux autres
manipulateurs, celui-là a une conséquence sur chaque élément écrit.


Justement : Dès que je veux "out-streamer" un vector / list / collection
quelconque d'objets, je veux typiquement afficher tous les éléments avec la
même largeur : Etre obligé de réappliquer setw pour chaque élément est à la
fois lourd dans le code et très probablement pénalisant en terme de
performances.

Arnaud

Avatar
Cyrille
Michel Michaud wrote:


J'imagine qu'on peut trouver plusieurs raisons, mais essaie simplement
de faire la moindre écriture complexe sans... Contrairement aux autres
manipulateurs, celui-là a une conséquence sur chaque élément écrit.



Justement : Dès que je veux "out-streamer" un vector / list / collection
quelconque d'objets, je veux typiquement afficher tous les éléments avec la
même largeur : Etre obligé de réappliquer setw pour chaque élément est à la
fois lourd dans le code et très probablement pénalisant en terme de
performances.


Vous trouverez peut-être votre bonheur dans ces deux librairies:
http://www.boost.org/libs/format/index.html
http://www.boost.org/libs/io/doc/ios_state.html


Avatar
Michel Michaud
Dans le message 4238c7c4$0$28024$,
Michel Michaud wrote:
[... commentaires sur les manipulateurs ...]



Vous trouverez peut-être votre bonheur dans ces deux librairies:
http://www.boost.org/libs/format/index.html
http://www.boost.org/libs/io/doc/ios_state.html


Je ne crois pas que ça règle les « problèmes » des flux standards
(s'il y a de tels problèmes...) :-)

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/


Avatar
kanze
Michel Michaud wrote:
Dans le message
,
a écrit
:

D'où la question suivante : *Pourquoi* avoir fait un cas
particulier pour la largeur????


J'imagine qu'on peut trouver plusieurs raisons, mais essaie
simplement de faire la moindre écriture complexe sans...
Contrairement aux autres manipulateurs, celui-là a une
conséquence sur chaque élément écrit.


Oui, mais c'est un raisonement circulaire. Avec printf, la
précision a bien un effet sur une chaîne de caractères ; si elle
n'en a pas en C++, c'est sans doute parce que, étant persistant,
ça donne des effets perverses.

À l'inverse, suppose que fixed et setprecision ne soient pas
persistants... (bah, ça ne serait pas si mal, si c'était setp
au lieu de setprecision :-)


Et qu'est-ce que ça changerait, s'ils n'était pas persistants ?
Tu précèdes normalement chaque champs par un manipulateur quand
même, qui précise comment le formatter d'une manière sémantique
(c-à-d qu'on dit que ses de l'argent, ou un pourcentage, ou...,
et qu'on définit une fois dans le programme comment l'argent et
les pourcentages doivent être formattés).

(Et ça vaut évidemment surtout pour des grosses applications.
Pour des petits bricolages rapides, il serait bien de
l'« overkill ».)

En fait, il ne faut pas oublier l'histoire non plus. La plupart
des manipulateurs d'aujourd'hui sont (plus ou moins) des
inventions du comité. Or, sans la persistence ni des
manipulateurs, ça aurait été bien pénible. (Je dis « plus ou
moins » l'invention du comité, parce que Jerry Schwarz y avait
bien pensé, mais ne les a pas implémenté pour éviter de trop
poluer l'espace référentiel global, et que c'est bien lui qui a
dit que maintenant qu'il y avait des namespace, ça serait une
bonne idée d'y aller.)

--
James Kanze GABI Software
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


1 2