Equivalent de printf("%#.2X", 2) avec les streams - C++ (French)

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

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

C++Talk.NET Forum Index -> C++ (French)

View previous topic :: View next topic

Author

Message

adebaene@club-internet.fr
Guest

Posted: Wed Mar 16, 2005 2:39 pm Post subject: Equivalent de printf("%#.2X", 2) avec les streams

Tout est dans le titre... printf("%#.2X", 2) affiche "0x02" (avec un 0 à gauche pour afficher 2 caractères). Quel est l'équivalent avec les flux ?? cout< Que mettre à la place de ????? Ni setw ni setposition ne donnent le résultat désiré.... J'ai l'impression que les flux ne permettent pas de controler la largeur minimale d'afficahge d'un entier. J'ai loupé quelque chose? Arnaud

xavier
Guest

Posted: Wed Mar 16, 2005 3:11 pm Post subject: Re: Equivalent de printf("%#.2X", 2) avec les streams

[email]adebaene (AT) club-internet (DOT) fr[/email] a dit le 16/03/2005 15:39:

Quote:

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

adebaene@club-internet.fr
Guest

Posted: Wed Mar 16, 2005 3:36 pm Post subject: Re: Equivalent de printf("%#.2X", 2) avec les streams

xavier wrote:

Quote:

adebaene (AT) club-internet (DOT) fr 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 ! #include !
! 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

kanze@gabi-soft.fr
Guest

Posted: Wed Mar 16, 2005 3:54 pm Post subject: Re: Equivalent de printf("%#.2X", 2) avec les streams

adeba... (AT) club-internet (DOT) fr wrote:

Quote:

xavier wrote:
[email]adebaene (AT) club-internet (DOT) fr[/email] 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 ! #include
! 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.

Quote:

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

adebaene@club-internet.fr
Guest

Posted: Wed Mar 16, 2005 4:10 pm Post subject: Re: Equivalent de printf("%#.2X", 2) avec les streams

k... (AT) gabi-soft (DOT) fr wrote:

Quote:

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????

Quote:

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

Michel Michaud
Guest

Posted: Wed Mar 16, 2005 4:24 pm Post subject: Re: Equivalent de printf("%#.2X", 2) avec les streams

Dans le message [email]1110989445.179450.207630 (AT) l41g2000cwc (DOT) googlegroups.com[/email],
[email]adebaene (AT) club-internet (DOT) fr[/email] <adebaene (AT) club-internet (DOT) fr> a écrit :

Quote:

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 [email]mm (AT) gdzid (DOT) com[/email]
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

kanze@gabi-soft.fr
Guest

Posted: Wed Mar 16, 2005 4:32 pm Post subject: Re: Equivalent de printf("%#.2X", 2) avec les streams

adeba... (AT) club-internet (DOT) fr wrote:

Quote:

k... (AT) gabi-soft (DOT) fr 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

Arnaud Debaene
Guest

Posted: Wed Mar 16, 2005 9:25 pm Post subject: Re: Equivalent de printf("%#.2X", 2) avec les streams

Michel Michaud wrote:

Quote:

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

Cyrille
Guest

Posted: Wed Mar 16, 2005 11:59 pm Post subject: Re: Equivalent de printf("%#.2X", 2) avec les streams

Arnaud Debaene a écrit :

Quote:

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

Michel Michaud
Guest

Posted: Thu Mar 17, 2005 1:45 am Post subject: Re: Equivalent de printf("%#.2X", 2) avec les streams

Dans le message 4238c7c4$0$28024$626a14ce (AT) news (DOT) free.fr,
Cyrille <cyrille (AT) frsf (DOT) invalid> a écrit :

Quote:

Arnaud Debaene a écrit :
Michel Michaud wrote:
[... commentaires sur les manipulateurs ...]

Quote:

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 [email]mm (AT) gdzid (DOT) com[/email]
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

kanze@gabi-soft.fr
Guest

Posted: Thu Mar 17, 2005 7:51 am Post subject: Re: Equivalent de printf("%#.2X", 2) avec les streams

Michel Michaud wrote:

Quote:

Dans le message
[email]1110989445.179450.207630 (AT) l41g2000cwc (DOT) googlegroups.com[/email],
[email]adebaene (AT) club-internet (DOT) fr[/email] <adebaene (AT) club-internet (DOT) fr> 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.

Quote:

À 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 Smile

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

kanze@gabi-soft.fr
Guest

Posted: Thu Mar 17, 2005 8:11 am Post subject: Re: Equivalent de printf("%#.2X", 2) avec les streams

Cyrille wrote:

Quote:

Arnaud Debaene a écrit :
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.

Attention : si la largueur était persistante, elle jouerait non
seulement sur les éléments, mais aussi sur les séparateurs. Or,
je doute beaucoup que chaque fois que tu veux que l'élément ait
une largueur de 10, tu veux aussi que le virgule séparateur
entre les éléments soit précédés de 9 espaces.

Quote:

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

Quel rapport ?

Le premier permet un formattage à la printf, au moins en ce qui
concerne les options de formattage les plus utiles. Ça peut être
utile, mais dans le cas en question, je ne vois pas ce que ça
apporte par rapporte à un manipulateur bien conçu. Un des gros
avantages de cette version de format, par rapport à la mienne,
d'ailleurs, c'est qu'il supporte l'utilisation des manipulateurs
aussi (je crois). Parce que la plupart du temps, il est
préférable que la spécification du formattage (largueur,
précision, etc.) soit bien séparé du texte.

Le seconde n'est qu'une application du concepte RAII à la
restitution de l'état de formattage à son état initial. Chose
que n'importe qui a bien déjà dans sa boîte à outils, depuis dix
ans ou plus. C'est utile, mais il n'aide en rien la gestion du
formattage même. (Dans mon cas, je dois dire que je n'utilise
prèsque plus mon propre IOSave, étant donné que tous mes
manipulateurs réstaure l'état dans leur déstructeur.)

En fait, pour ce genre de problème, j'utilise toujours un
manipulateur sur mésure -- si c'est des flottants, par exemple,
j'ai une classe prédéfinie FixFmt, qui prend deux paramètres, le
largueur et la précision, et qui permet à écrire des choses
comme:

for ( int i = 0 ; i < v.size() ; ++ i ) {
if ( i != 0 ) {
dest << ", " ;
}
dest << FixFmt( 10, 2 ) << v[ i ] ;
}

Quant aux performances...

FixFmt réstaure tous l'état de formattage dans son déstructeur.
J'effectue donc bien plus de travaille que nécessaire. N'empèche
que je n'ai jamais rencontré un cas où ça avait de
l'importance ; le temps reste négligeable par rapport au temps
nécessaire au formattage d'un flottant. Il ne faut pas exagérer
quand même. (Mais si le profiler disait que c'était un problème,
c'est trivial de déclarer une instance de FixFmt en dehors de la
boucle, et s'en servir.)

--
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

Cyrille
Guest

Posted: Thu Mar 17, 2005 9:05 am Post subject: Re: Equivalent de printf("%#.2X", 2) avec les streams

[email]kanze (AT) gabi-soft (DOT) fr[/email] a écrit :

Quote:

Cyrille wrote:

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

Quel rapport ?

Euh en fait, je réagissais surtout en rapport avec le titre de ce thread
"Equivalent de printf("%#.2X", 2) avec les streams".
Voilà, la première librairie fournit ça en apportant un formattage à la
printf avec les streams (et un peu plus). Evidemment, c'est une toute
autre philosophie que les manipulateurs standards. J'aurais peut-être dû
répondre en début de thread.

Quote:

Le seconde n'est qu'une application du concepte RAII à la
restitution de l'état de formattage à son état initial. Chose
que n'importe qui a bien déjà dans sa boîte à outils, depuis dix
ans ou plus. C'est utile, mais il n'aide en rien la gestion du
formattage même. (Dans mon cas, je dois dire que je n'utilise
prèsque plus mon propre IOSave, étant donné que tous mes
manipulateurs réstaure l'état dans leur déstructeur.)

Oui, ok. C'est peu pertinent.

Michel Michaud
Guest

Posted: Thu Mar 17, 2005 4:02 pm Post subject: Re: Equivalent de printf("%#.2X", 2) avec les streams

Dans le message [email]1111045910.386744.49590 (AT) o13g2000cwo (DOT) googlegroups.com[/email],
[email]kanze (AT) gabi-soft (DOT) fr[/email] <kanze (AT) gabi-soft (DOT) fr> a écrit :

Quote:

Michel Michaud wrote:
Dans le message
[email]1110989445.179450.207630 (AT) l41g2000cwc (DOT) googlegroups.com[/email],
[email]adebaene (AT) club-internet (DOT) fr[/email] <adebaene (AT) club-internet (DOT) fr> 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.

Mais, avec printf, les éléments non formatés (entre les %) sont
affichés tel quel. Le formatage par printf est donc finalement très
différent du formatage des flux de C++ et il devient difficile de
justifier un en utilisant l'autre...

De toute façon, on a ce qu'on a dans ISO C++ et si on veut en
ajouter ou utiliser autre chose, it's easy enough :-)

Quote:

À 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).

J'ai l'habitude de tout spécifier à chaque bloc d'écriture, mais
pas à chaque valeur écrite. C'est un habitude qui va bien avec la
persistance de setprecision et fixed en particulier.

Par contre, à l'usage, je considère que setfill aurait avantage à
ne pas être persistant. En fait, pour faire plaisir à tout le
monde l'idéal aurait été d'avoir deux versions de chacun des
manipulateurs : une persistante, une non persistante :

<< fixed << precision(2) << width(5) << fill('*') // non persistant
<< var1
<< setfixed << setp(2) << setw(5) << setfill('*') // persistant
<< var2 << var3

Il y aurait un problème avec cette approche ?

--
Michel Michaud [email]mm (AT) gdzid (DOT) com[/email]
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

kanze@gabi-soft.fr
Guest

Posted: Fri Mar 18, 2005 7:45 am Post subject: Re: Equivalent de printf("%#.2X", 2) avec les streams

Michel Michaud wrote:

Quote:

Dans le message
[email]1111045910.386744.49590 (AT) o13g2000cwo (DOT) googlegroups.com[/email],
[email]kanze (AT) gabi-soft (DOT) fr[/email] <kanze (AT) gabi-soft (DOT) fr> a écrit :
Michel Michaud wrote:
Dans le message
[email]1110989445.179450.207630 (AT) l41g2000cwc (DOT) googlegroups.com[/email],
[email]adebaene (AT) club-internet (DOT) fr[/email] <adebaene (AT) club-internet (DOT) fr> 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.

Mais, avec printf, les éléments non formatés (entre les %)
sont affichés tel quel. Le formatage par printf est donc
finalement très différent du formatage des flux de C++ et il
devient difficile de justifier un en utilisant l'autre...

Tout à fait. En fait, une des faiblesses, si on veut dire, du
paradigme C++, c'est qu'il ne distingue pas les chaînes champs
d'affichage (les %s du printf) des chaînes remplissage (le texte
en dehors des % du printf). Alors que pour les premières, des
paramètres comme largueur et précision sont significatifs, et
pour les secondes, il ne les faut absolument pas.

Il faut donc que tout paramètre qui affecte une chaîne soit
volatile ; qu'il n'affecte que la chaîne qui lui suit
immédiatement. N'empèche que j'aurais fait que la précision
affecte les chaînes (comme dans printf), quitte à le rendre
volatile.

Et en passant, je dois ajouter qu'en fait, la distinction
volatile/persistant n'est qu'une convention, suivi de tous les
inserteurs et les extracteurs de la norme, mais à charge des
inserteurs et des extracteurs. Rien n'interdit d'écrire un
inserteur qui remet à zéro la précision, mais non la largueur,
par exemple. Malheureusement.

Quote:

De toute façon, on a ce qu'on a dans ISO C++ et si on veut en
ajouter ou utiliser autre chose, it's easy enough Smile

Been there, done that:-).

Quote:

À 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).

J'ai l'habitude de tout spécifier à chaque bloc d'écriture,
mais pas à chaque valeur écrite. C'est un habitude qui va bien
avec la persistance de setprecision et fixed en particulier.

J'imagine que ça dépend beaucoup de ce qu'on fait. Dans la
pratique, je constate qu'il y a deux cas distinctes (et sans
doute plus, mais deux fréquents dans mon travail) : le texte
« normal » et les tableaux. Dans le texte normal, c'est rare
d'avoir plus d'un ou deux champs, et même alors, les différents
champs ont typiquement des sémantiques et des types
différents. Ce qui veut dire que la persistance ne me sert à
rien ; il faut tout spécifier à chaque champs. Dans les
tableaux, c'est un peu plus complexe, mais en général, ce sont
les colonnes qui détermine la sémantique et le type, alors qu'on
sort les données par ligne. Du coup, là aussi, il faut tout
spécifier à chaque champ.

J'imagine que dans les domaines où le calcul numérique est
important, il arrive qu'on sort des matrices, où et les colonnes
et les lignes ont tous le même type et la même sémantique. Dans
ce cas-là, c'est vrai que la persistance doit être bien
intéressante.

Quote:

Par contre, à l'usage, je considère que setfill aurait
avantage à ne pas être persistant. En fait, pour faire plaisir
à tout le monde l'idéal aurait été d'avoir deux versions de
chacun des manipulateurs : une persistante, une non
persistante :

fixed << precision(2) << width(5) << fill('*') // non persistant
var1
setfixed << setp(2) << setw(5) << setfill('*') // persistant
var2 << var3

Il y aurait un problème avec cette approche ?

Je suis tout à fait de cet avis. D'autant plus qu'on a déjà deux
méthodes de positionner chaque champs : avec un fonction membre
de ios, et avec un manipulateur. Je le trouverais tout à fait
logique que les valeurs positionnées par fonctions membres
soient persistantes, et que celles positionnées par les
manipulateurs ne les soient pas.

L'implémentation, c'est moins évidente, mais je crois que c'est
jouable. Il faudrait évidemment un flag par valeur (et des
fonctions membres distinctes pour chaque champs dans setf) ; il
serait bien aussi que la rémise à zéro se fait dans le
destructeur de l'objet sentry, de façon à ce qu'on ne dépend pas
des inserteurs et des extracteurs (éventuellement écris par
l'utilisateur) d'implémenter cette logique un peu plus
compliquée.

--
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

Display posts from previous:

	C++Talk.NET Forum Index -> C++ (French)	All times are GMT
Page 1 of 1

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum