ostringstream effacer

"Ael Rowan Terence" <Nul@Null.fr> a écrit dans le message de news:
f6l4r5$6p1$1@news1.completel.net...

J'en conclue que même la demande la plus basique amènent à des extremes
hallucinants.

C'est vrai, mais il ne faut pas se méprendre sur les raisons derrière ça,
qui ont assez peu à voir avec un gout prononcé pour la polémique (même si ça
reste bien sur possible) mais plutôt avec le fait que les systèmes
contemporains sont extrèmement complexes.

C'est particulièrement vrai pour le C++, qui reste un langage
particulièrement complexes.

Tout le debat sur faut-il utiliser ça à la place de ça, je ne veux pas y
prendre part.
Cela ne m'interesse pas.

Alors n'y prends pas part, c'est ton droit, mais ça ne le rend pas pour
autant illégitime. Ce sont ces débats qui permettent l'emergence de
pratiques saines et idiomatiques, et je pense que les interventions de james
sont plus à prendre dans ce sens que dans celui d'une solution ponctuelle à
un problème technique immédiat.

L'intéret n'est pas évident pour un contributeur ponctuel, qui soumet un
problème précis, mais il l'est pour la communauté C++ qui voit par là
augmenter sa maitrise collective du langage.

"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le message
de news:468e10f1$0$27370$ba4acef3@news.orange.fr...

"Ael Rowan Terence" <Nul@Null.fr> a écrit dans le message de news:
f6l2hg$6i5$1@news1.completel.net...

"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le
message

C'est bien ce que je dis, à la suite de James et des tiennes maintenant
,

certaines implémentations invalideront ton affirmation :
plus rapide en temps d'execution.

Non. James dit juste qu'on ne peut pas l'affirmer à l'avance.

2- On s'en fout que ce soit plus rapide ou non tant qu'il n'est pas
établi
(via un profiling) qu'on a besoin de quelque chose de rapide.

Ha bon ! si "on s'en fout" , je me demande pourquoi même tu
l'évoques.

Je résumais ce que disait james, pas ce que je disais moi.

Mais ne serait-ce pas plus simple si tu parlais en ton nom ?
Parce que ta façon de résumer est par trop personalisée.

Et du fait, tu lui attribues des propos qu'il na pas eu.

Pour ma part je ne m'en fout pas, mais comme ce n'était pas le but de ma
demande, cela ne derange pas de suspendre ce point.

C'est précisément parce qu'on a souvent pour (mauvaise) habitude de penser

Encore un affirmation à l'emporte piece, les reserves d'usages vont de soit,
bien entendu.

un peu à la vitesse dès la phase de codage que j'ai parlé du temps
d'exécution, afin qu'une hypothétique lenteur ne soit pas retenue comme
critère pour ne pas créer un nouveau flux.

[...]

Sans que cela n'ait été dit explicitement, on a tout de même parlé de la

Sans doute un effet de bord de ta façon de résumer, qui embrouille plus
qu'elle n'éclaircit.

gestion des ressources (sylvain avec son "développement durable", james
avec

le temps du développeur), et je trouve donc légitime de parler d'une autre
ressource, à savoir le temps d'exécution, dans la mesure où on pourrait
être

tenté de ne pas créer un nouveau flux afin de "gérer les ressources".

[...]

Les réserves d'usage concernant les performances sont celles qu'a rappelé
james : les performances réelles doivent être testées au cas par cas, et
on

ne doit s'en soucier qu'une fois qu'il a été établi qu'elles posaient
problème.

Ton affirmation sujet du "temps d'execution" m'est apparue fort contestable.

Maintenant James dit

<Citation>
D'ailleurs, même une fois qu'on l'a vérifié, on ne sait que pour une
implémentation donnée ; ça pourrait être completement l'opposé avec une
autre implémentation
<Citation/>,

tu ne contredis pas James.

J'en conclue que ton affirmation manque de fondement.
Tu t'es engagé un peu à la légère, soit, passons à autre chose, non ?

"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le message
de news:468e1f97$0$27414$ba4acef3@news.orange.fr...

"Ael Rowan Terence" <Nul@Null.fr> a écrit dans le message de news:
f6l4r5$6p1$1@news1.completel.net...

Tout le debat sur faut-il utiliser ça à la place de ça, je ne veux pas y
prendre part.
Cela ne m'interesse pas.

Alors n'y prends pas part, c'est ton droit, mais ça ne le rend pas pour

Mais je n'y prends pas part, c'est bien ce que j'essaye de te faire
comprendre.
Je te réponds parce que tu m'attribues des intentions qui ne sont pas les
miennes.

autant illégitime. Ce sont ces débats qui permettent l'emergence de
pratiques saines et idiomatiques, et je pense que les interventions de
james

sont plus à prendre dans ce sens que dans celui d'une solution ponctuelle
à

un problème technique immédiat.

Tout a fait honorable, ce n'est pas moi qui te reprocherais cela.

L'intéret n'est pas évident pour un contributeur ponctuel, qui soumet un
problème précis, mais il l'est pour la communauté C++ qui voit par là
augmenter sa maitrise collective du langage.

Si tu y trouve ton compte, cela ne me pose pas de problème.

Si tu n'essaye pas de me faire dire ce que je n'est pas dit, pour moi c'est
OK.

"Ael Rowan Terence" <Nul@Null.fr> a écrit dans le message de news:
f6l8go$739$1@news1.completel.net...

L'intéret n'est pas évident pour un contributeur ponctuel, qui soumet un
problème précis, mais il l'est pour la communauté C++ qui voit par là
augmenter sa maitrise collective du langage.

Si tu y trouve ton compte, cela ne me pose pas de problème.

Si tu n'essaye pas de me faire dire ce que je n'est pas dit, pour moi
c'est
OK.

Je n'essaie pas de te faire dire quoi que ce soit mais juste de clarifier ce
qui me semble relever du malentendu. :)

"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le message
de news:468e2609$0$25954$ba4acef3@news.orange.fr...

"Ael Rowan Terence" <Nul@Null.fr> a écrit dans le message de news:
f6l8go$739$1@news1.completel.net...

L'intéret n'est pas évident pour un contributeur ponctuel, qui soumet
un

problème précis, mais il l'est pour la communauté C++ qui voit par là
augmenter sa maitrise collective du langage.

Si tu y trouve ton compte, cela ne me pose pas de problème.

Si tu n'essaye pas de me faire dire ce que je n'est pas dit, pour moi
c'est
OK.

Je n'essaie pas de te faire dire quoi que ce soit mais juste de clarifier
ce

qui me semble relever du malentendu. :)

Super, s'il n'y plus de malentendu, au moins entre nous deux, c'est deja un
bien.

"Michael DOUBEZ" <michael.doubez@free.fr> a écrit dans le message de
news:468cdd57$0$21197$426a74cc@news.free.fr...

J'ai entendu ses remarques. Mais en l'occurence pour le cas qui m'occupe
je n'ai pas besoin de plus que de oss.str(""). Que dire de plus ?
Rien. James et Sylvain peuvent continuer la discution :) Ca nous permet

a tous d'approfondir les aspects du problème.

J'ai relu son post de 10:24 en reponse à Sylvain, mais, c'est du délire.

Je l'ai lu et je suis assez d'accord avec ce qu'il a écrit.

Mon principe personnel est la règle de l'étonnement minimum:

1. Un collègue ne devrait pas être étonné:
Tiens, il a mis une méthode reset()?
il doit y avoir une raison pour ça, je vais chercher...non, rien.

2. Un client ne devrait pas être étonné:
Tiens, il a mis une fonction reset() ?
Dans quel cas doit je l'utiliser plutôt que de re-instancier. Je vais
appeler la hot-line (2h d'attente, passage au service technique, mail
...) et à la fin, un commentaire dans le code:
// TODO: use reset() method if reallocation doesn't work
// retry FooTech hot line between 10am and 2pm for info
// Tel: +33 1 56 ...

3. Tu ne devrais pas être étonné:
Quel est l'imbécile qui a écrit ce code ? ... Oh !

:)

Michael

Michael DOUBEZ wrote on 06/07/2007 13:55:

Mon principe personnel est la règle de l'étonnement minimum:

et tu l'appliques à chercher à nous étonner par tes cheminements ?

1. Un collègue ne devrait pas être étonné:
Tiens, il a mis une méthode reset()?
il doit y avoir une raison pour ça, je vais chercher...non, rien.

comme celui d'imaginer que *nécessairement* si quelqu'un ose une méthode
non coutumière des standards, il le fera a) dans son coin, b) sans en
discuter avec ses collèges, c) sans en informer les developpeurs ayant à
travailler avec ce code, ...

tu prends les gens pour des anes ou tu nous livres là tes frustrations ?

2. Un client ne devrait pas être étonné:
Tiens, il a mis une fonction reset() ?
Dans quel cas doit je l'utiliser plutôt que de re-instancier. Je vais
appeler la hot-line [...]

comme également celui d'imaginer que *nécessairement* toutes les
livraisons sont en code source [1], dans le monde du logiciel (et malgré
tous les charmes du libre ET ouvert) la plupart des livraisons sont,
faut-il te le rappeler, en binaire (libs et / ou exec).

[1] j'écarte évidemment les fournitures comme celles que pourrais faire
une SSII contractée pour fournir un source, car dans ce cas le
contractant aura évidemment fourni un cahier des charges complet - dans
le même temps je n'ai jamais vu pire code que justement ceux fourni dans
ce cadre, donc j'écarte doublement pour ne pas épiloguer sur ce cas.

3. Tu ne devrais pas être étonné:
Quel est l'imbécile qui a écrit ce code ? ... Oh !

l'écho n'étant sûrement pas là pour te répondre:
quel est l'imbécile qui a formulé cet avis ? ... Oh !
je suppose que ta formulation reflète ta conviction d'être génial et son
corrolaire nécessaire que les autres sont des imbéciles.

Sylvain.

James Kanze wrote on 06/07/2007 11:27:

C'est un peu plus que ça, parce que parmi l'état visible de
std::vector, il y a bien std::vector<>::capacity(). Et son effet
sur les garanties des itérateurs.

je n'ai pas regardé la dépendance des std::itérateurs envers la capacité
d'une collection mais j'espère qu'il n'en existe pas (pas trop); un
itérateur doit se soucier du nombre d'éléments contenus, pas du nombre
maximal possible.

Mais plus généralement, je pensais à une différence pas
forcement directement visible, mais qui peut avoir un effet
notable : le fait justement qu'il ne libère pas la mémoire. Tu
crée un vecteur avec une million d'éléments, puis tu fais
clear(), et tu lui insères un seul élément. Il utilise toujours
la mémoire pous une million.

pourquoi serait-ce la règle, ou plutôt une erreur obligeatoire ??

une stratégie d'allocation (lors d'insertion dans un flux comme dans une
collection) peut prendre en compte la taille courante et (pour un flux)
la taille de l'élément inséré.
une stratégie de libération peut prendre en compte la taille (la
capacité) courante - lors d'un empty() sur un tableau / une collection
d'un million d'éléments, je réduis la capacité de 90% (empiriquement).

C'est justement à cause de ces effets pas trop visible que
j'insiste : si tu veux un objet à l'état vièrge, il faut en
créer un nouveau.

une grosse partie de la discussion vient de cette (re)formulation que tu
fais de la question initiale!

dans "effacer un contenu courant" je lis "tout en gardant tous les
autres attributs"; répondre à comment créer un objet *vierge* n'était
pas cette question initiale, on ne voulais pas un objet vierge, on
voulais un objet "vide" (je quote car 'vide' n'est pas suffisamment self
explanatory).

non cela peut ne pas se justifer, si je génére un XML, je ne vais pas me
taper (systématiquement) une méthode pour définir chaque attribut texte
à formatter. si je génére un DER, je ne vais pas (systématiquement) me
taper une méthode pour encoder chaque data object.

Si je génère un XML, je vais générer le schéma complet dans un
seul flux, non ? Sans jamais le resetter. S'il me faut un flux
à part, je crois bien que j'en ferais une fonctionne à part.

XML n'est pas le meilleur exemple, des objets non primitifs ASN.1 en
seraient de meilleurs, je voulais indiquer un cas où chaque attribut
doit être construit via un flux (local à cet attribut) avant de pouvoir
injecter l'attribut complet dans le flux principal unique (par exemple
parce que la taille globale de l'attribut est nécessaire pour cette
injection) sans que l'on souhaite pour autant créer des méthodes pour
chaque attribut.

mais j'imagine la plupart du temps que la situation serait
l'inverse : que j'ai une fonction pour générer les attributes
(par exemple), et que cette fonction prend un ostream& en
entrée.

dans le cas simple ce sera suffisant (pour du texte au kilomètre, pas
nécessairement pour des structures emboitées).

dans un cas un peu moins trivial où, par exemple, les éléments pouvant
être traités seront injectés mais où les éléments ne pouvant pas l'être
(quelque que soit la raison de cette impossibilité) ne le seront pas
tout en garantissant l'intégrité / l'exactitude du flux global ce sera
bcp plus périlleux (au minimum double parcours pour tout tester avant de
commencer l'injection, puis injection effective), je préfère
définitivement un flux local (réutilisable) qui sera conditionnellement
injecté dans le flux principal.

Sylvain.

Michael DOUBEZ wrote on 06/07/2007 11:49:

je note ici que l'abstraction doit être une caractéristique forte d'un
flux.

En realité, les flux ne sont pas abstraits même du point de vue du
langage: il n'est pas possible d'hériter d'un flux.

je ne citais que James (sans chercher à contredire cette affirmation).

je n'introduisais pas un 'flux' comme nécessairement virtuel imposant un
schéma d'héritage (même si je l'utilise souvent ainsi) et évoquait
l'abstraction pour elle-même (sans héritage lié).

toutefois dans mon schéma polymorphe, je pensais plus à une abstraction
du code (des traitements) alors que vous (avec James) parlez plus
d'abstraction des données, vous refusant à associer la source des
sources des données (le "contenu") au flux, dont acte.

Comment effacer quelque chose qu'il n'y a pas, voilà la
question ?

ben ?! si il y a un contenu on l'efface [...]

Il s'agit donc bien d'effacer le contenu du streambuf sous-jacent en
supposant qu'il y en ait un.

comme dit ci-avant, pour moi il n'est pas si sous-jacent.

Sylvain.

"Sylvain" <noSpam@mail.net> a écrit dans le message de news:
468eab46$0$5087$ba4acef3@news.orange.fr...

toutefois dans mon schéma polymorphe, je pensais plus à une abstraction du
code (des traitements) alors que vous (avec James) parlez plus
d'abstraction des données, vous refusant à associer la source des sources
des données (le "contenu") au flux, dont acte.

Plus représentation d'un concept qu'abstraction des données (ou même du
code).