OVH Cloud OVH Cloud

ostringstream effacer

65 réponses
Avatar
Ael Rowan Terence
Pardonnez moi d'avance, je sais que le sujet à déjà été abordé, mais j'ai du
mal à comprendre.

Quelle procédure employer pour effacer le contenu d'un ostringstrem ?

10 réponses

Avatar
Ael Rowan Terence
"Christophe Lephay" a écrit dans le message
de news:468ce2ef$0$5068$
"Ael Rowan Terence" a écrit dans le message de news:
f6imiv$upt$
Je trouve sa réponse, à la question de James, dénuée d'intentions
négatives,
bien au contraire, frappée du sens de la mesure.


Je pense que tu te méprends sur ces intentions négatives que tu pretes à
James.


Techniquement je nattribue pas de sens négatif à la réponses de James, je
pense qu'il était indispensable d'apporter certaines précisions.
Cela étant.
J'ai essayé de faire comprendre que je voulais savoir si la possiblité
existait d'effacer un le contenu d'un flux, et c'est tout ce dont j'avais
besoin.

Alors que tout se résume à : je veux voir par moi-même ce qu'il en est,
l'insitance sur le "devoir justifier ma position", rend la chose ubuesque.


Ceci dit, je comprends que la réponse de sylvain te soit plus confortable.


Oui, je trouve qu'il a essayé de comprendre et de ramener le debat à un
niveau plus en relation avec la demande initiale, à un niveau plus modeste.


Avatar
Ael Rowan Terence
"Michael DOUBEZ" a écrit dans le message de
news:468cdd57$0$21197$
"Michael DOUBEZ" a écrit dans le message de
news:468cc112$0$12381$
"Christophe Lephay" a écrit dans le
message


de news:468be400$0$27388$




Je ne discute pas ton ressenti mais la phrase est sortie de son
contexte. Il explique ensuite ce qu'il a compris et ce qu'il pense que
les autres ont compris.

<reprise>
Chacun peut comprendre ce qu'il veut.

Ce que je comprends, c'est que le PO veut effacer un flux sans vraiment
savoir de quoi il s'agit. On peut lui indiquer comment en effacer la
string,
et répondre donc à sa question telle que tu l'as compris, ou alors lui
indiquer qu'il risque, ce faisant, de se tirer une balle dans le pied
selon

l'état du flux et l'usage qu'il en fait.
</reprise>


Oui, je reconnais, je n'avais pas bien compris ce qu'il disait.


[snip]
Quant à James, est-il vraiment nécessaire que je justifie pourquoi le
seul


__ oss.str("")__ , suffit pour resourdre ma problématique.
Alors que je lui avait deja donné les réponses à ces questions, avec un
exemple refletant ce dont j'avais besoin. C'est à dire une truc
simplissime.



James parle avec toi comme il parlerait avec une personne en technical
review je suppose. Il essaye de mettre au clair pourquoi tu préfères une
solution à priori suboptimale.


Le problème est qu'il monte un peu vite dans les tours.
La demande est "existe-t-il une possibilité d'effacer le contrenu d'un
ostringstream".
Lui en est à l' "ontologie professionnelle".


Et tu n'es pas le seul en cause. D'autre personnes vont lire ces
messages et si tout n'est pas dit, ça peut les tromper.


Là où je suis plus d'accord avec toi c'est sur le "si tout n'est pas dit".
Vu comme ça part dans tous les sens, avant que "tout" soit dit cela risque
d'etre très long.


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.




Avatar
Christophe Lephay
"Ael Rowan Terence" a écrit dans le message de news:
f6ir77$v70$
J'ai essayé de faire comprendre que je voulais savoir si la possiblité
existait d'effacer un le contenu d'un flux, et c'est tout ce dont j'avais
besoin.

Alors que tout se résume à : je veux voir par moi-même ce qu'il en est,
l'insitance sur le "devoir justifier ma position", rend la chose
ubuesque.


Je vais tenter de résumer.

Je pense qu'on peut commencer par distinguer le cas général du cas
particulier.

Le cas général, c'est qu'un flux correspond à quelque chose de précis en
c++, tant du point de vue du concept que de ses implémentations, et que
vouloir utiliser un stringstream comme un string est donc potentiellement un
mauvais choix ou une erreur de design.

On peut réinitialiser *partiellement* un stringstream via son membre str,
eventuellement réinitialiser ses bits d'état avec clear, sa position avec
seekp, mais moins le flux sera localisé, plus il y aura de risques d'avoir
des bugs.

Le cas général, donc, consiste à coder de manière à éviter un "reset", a
fortiori sur des flux qui sont reçus ou transmis comme paramètres.

Les cas particuliers, c'est quand on définit soi-même des flux qui diffèrent
conceptuellement des flux standards ou quand, de manière exceptionnelle, on
souhaite réinitialiser partiellement un flux *en connaissance de cause*.

A noter qu'une règle assez fondamentale en programmation consiste à choisir
ou concevoir ses abstractions ou algorithmes de manière à éviter autant que
possible les cas particuliers.

Avatar
Christophe Lephay
"Ael Rowan Terence" a écrit dans le message de news:
f6iu66$vfr$
"Michael DOUBEZ" a écrit dans le message de
James parle avec toi comme il parlerait avec une personne en technical
review je suppose. Il essaye de mettre au clair pourquoi tu préfères une
solution à priori suboptimale.


Le problème est qu'il monte un peu vite dans les tours.
La demande est "existe-t-il une possibilité d'effacer le contrenu d'un
ostringstream".


Sans doute, mais on sera d'accord, j'en suis sur, sur le fait que ce forum
n'est pas une hotline pour résoudre des problèmes techniques personnels. Il
est extrèmement enrichissant de tenter de passer d'un cas particulier à un
cas plus général, et inversement. C'est par ce biais qu'on développe des
techniques, des idiomes, des patterns, etc, et c'est la vocation principale
d'un forum technique sur usenet (à mon sens).


Avatar
Ael Rowan Terence
"Christophe Lephay" a écrit dans le message
de news:468d0a62$0$25911$
"Ael Rowan Terence" a écrit dans le message de news:
f6iu66$vfr$
"Michael DOUBEZ" a écrit dans le message de
James parle avec toi comme il parlerait avec une personne en technical
review je suppose. Il essaye de mettre au clair pourquoi tu préfères
une



solution à priori suboptimale.


Le problème est qu'il monte un peu vite dans les tours.
La demande est "existe-t-il une possibilité d'effacer le contrenu d'un
ostringstream".


Sans doute, mais on sera d'accord, j'en suis sur, sur le fait que ce forum
n'est pas une hotline pour résoudre des problèmes techniques personnels.
Il

est extrèmement enrichissant de tenter de passer d'un cas particulier à un
cas plus général, et inversement. C'est par ce biais qu'on développe des
techniques, des idiomes, des patterns, etc, et c'est la vocation
principale

d'un forum technique sur usenet (à mon sens).



Sans aucune réticence, d'accord avec toi sur ce que devrait etre un beau
forum.
Cela incluant le droit d'exprimer son desacord quand se produisent des
dérapages.

Et lorsque je lis :

<Citation>
C-à-d que tu n'en as pas compris l'abstraction, et donc que tu l'as violé.
J'espère ne jamais avoir à maintenir du code que tu as écrit.
<Citation/>

Je ne trouve plus le coté "enrichissement technique" .



Avatar
Alain Gaillard
Si l'exemple et les réponses apportées plus haut ne suffisent pas pour
eclaircir se que je veux faire, je préfère abandonner cette conversation qui
ne mene nulle part.


James en programmeur C++ très expérimenté qu'il est, je devrais même
dire expert en fait, voulait te mener vers la solution naturelle, qui
devrait s'imposer naturellement à toi.

--
Alain

Avatar
Alain Gaillard

Tu te rends compte de ce que tu dis ? Encore l'exemple de
"/dev/tty" (je crois que c'est "CONS" sous Windows, mais je ne
suis pas sûr).


Sous Windows c'est CON.
C'est forcément CON sous Windows, tu devrais le savoir ;)
Lol

--
Alain

Avatar
Sylvain
James Kanze wrote on 05/07/2007 10:24:

tu n'as pas le même post que moi ? pour ma part je lis "Quelle procédure
employer pour effacer le contenu d'un ostringstrem".


Alors, il y a un problème, parce qu'un flux n'a pas de
« contenu ». Ça ne fait pas parti de l'abstraction d'un flux.


disons que cela dépendra du background de l'auteur, pour moi un 'flux' a
(dans la plupart des cas) un contenu, sinon c'est un pipe, un injecteur,
un formatteur.

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

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


ben ?! si il y a un contenu on l'efface, si il n'y en a pas on ne fait
rien, ou on assert ou on throw, ou ..., on le dis juste dans la spec. non ?

D'un sens réel, un flux n'a pas de contenu ;
il s'apparente plus à un itérateur qu'à une collection.


ce point est réducteur et cette réduction me parait même erronée.

un flux d'injection a un contenu et ce contenu est ce qui a été injecté.


std::ofstream f( "/dev/tty" ) ;


erase() { f << (char) 12; }
ça marche depuis 30+ ans non ?


Tu vas me dire que f a un contenu. Tu vas me dire que ça a un
sens d'« effacer » le contenu. Dans le cas de ostringstream,
il y a bien une collection derrière, mais ostringstream présente
à surtout l'interface d'un flux. On peut facilement récupérer la
chaîne qu'on a générée, mais au delà, on joue avec le feu.


pas compris - 'ostringstream' ne voulait sûremnt pas être cité en
opposition dans les 2 cas.

un flux d'extraction a un contenu et ce contenu est (au minimum) ce qui
n'a pas encore été extrait (on peux selon le type concrêt de la source
imaginer un rewind qui redonne accès au contenu initial intégral).


Tu te rends compte de ce que tu dis ? Encore l'exemple de
"/dev/tty" (je crois que c'est "CONS" sous Windows, mais je ne
suis pas sûr). Voire même n'importe quel fichier ; le
« contenu » du fichier ne change pas lors de l'extraction, à
ce que je sache.


je n'ai pas dit qu'un fichier *extrait* (parcouru) changeait - seul le
"pointeur de lecture" change, c'est lui que je rembobinais, remettais au
début du fichier.


Encore une fois, l'abstraction fondamentale des iostream, c'est
un flux. C'est beaucoup plus proche à un itérateur qu'à une
collection. Comme un itérateur, il peut y avoir une collection
derrière, ou non, selon le cas. Et comme un itérateur, il n'y a
pas de sense de parler d'en effacer le contenu.


je note que l'abstraction est non seulement une caractéristique forte
d'un flux mais même fondamentale.

c'est que qui me gène dans l'approche, je dis bien dans le style ! pas
sur le fond: que std::ostringstream ne soit pas prévu pour cela et qu'il
soit déconseillé de tirer parti de ce que semble faire telle méthode
n'est pas une solution, tu l'as expliqué et évidemment je n'oppose rien
à cela.

mais l'approche (jouée sous la forme d'argument d'autorité, pardon pour
la redite) cela est impossible (en général, et pas que pour cette
implémentation là) parce que nécessairement l'abstraction fondamentale
... est là pour me casser les pieds ?? me gène un peu.

dans un autre fil ("Problème d'héritage"), tu résumes (avec raison)
qu'un problème doit être regardé dans son contexte propre et (dans cet
exemple) que la réponse se trouve dans ce contexte.

de la même façon, j'ai la faiblesse de penser que si une abstraction est
nécessaire dans la défintion des services d'un flux, l'implémentation
concrête d'un type de flux particulier peut trouver des réponses
(spécialisations) évidentes et pertinentes pour ce flux (comme définir
une chaine à '' ou effacer un shell).

toutes mes classes d'injections ont des méthodes "empty" et selon le
type réel, j'oublie / efface / supprime une chaine, ou un contenu
(partiel ou complet) de fichier.


Alors, tu n'as pas bien compris l'abstraction que tu essaies
d'implémenter. Comme j'ai dit, les classes d'injection de la
norme ne l'ont pas.


euh si, j'ai très bien compris l'abtraction que je code.

notre approche n'est sûrement pas la même, en court, je pose
généralement l'abstraction comme une proposition de services génériques
que je résouds par le polymorphisme; tu sembles définir l'abstraction
comme quelque chose d'auto-contenu dans un seul concept pourtant
générique, dans un tel cas, l'objet en question n'a pas d'autre choix
que d'être restrictif.


En fait, même les classes de collection de
la norme ne l'ont pas ; leur fonction « empty() » ne ramène
pas la collection à son état initial.


il s'agit - enfin j'espère - de rester pragmatique et efficace - mon
expérience n'est pas que du "chez moi, paour m'amuser" - remettre à son
état initial doit (aurait dû) être compris comme l'état visible de
l'extérieur et non moultes détails d'état interne comme tel buffer,
array ou autre point invisible au code utilisateur.

On peut ne pas être
d'accord ; moi aussi, j'aime bien les fonctions « reset() »,
qui amène l'objet à l'état « vient d'être construit ». Mais
une telle fonction n'existe pour prèsqu'aucune classe dans la
norme. (std::auto_ptr est l'exception.)


dont acte et ? on n'en parle jamais parce que fr.comp.lang.c++ n'est que
fr.comp.lang.std, ou on peut discourir de ce que le C++ permets ???

pour re-illustrer le point précédent, je redirais qu'un flux est
précisément et avant tout ce contenu que l'on peut modifier (par
adjonction) et naturellement supprimer.


Seulement que c'est manifestement faux.


pour les flux de std.

J'avoue que je ne peux pas imaginer un tel cas. Ça serait trois
fonctions différentes, non ? Chacune avec son flux. La question
serait plutôt quelque chose comme :


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.

while ( ... ) {
xxxxStream stream ;
// ...
}


et tout ne se code pas comme un "while(y-a-des-attributs)".
(ce XML est ici est un mauvais exemple :))

C-à-d que tu n'en as pas compris l'abstraction, et donc que tu
l'as violé.


l'abstraction de quoi ?

si je tape
class machin {
void empty();
};
je viole qui ??
rassure-moi vite des milliers de procès m'attendent.


J'espère ne jamais avoir à maintenir du code que tu as écrit.


comme cela à une probabilité nulle (voire moins) d'arriver, je ne vois
pas pourquoi tu nourris cet espoir; dans le même temps tu ne pourrais
pas le faire et pas à cause de cela; donc n'angoisses pas!

Il y a bien une ontologie professionnelle, non ?


j'ai lu celle, un peu phénoménologique, de Sartre mais celle du
développeur C++ n'était pas au programme cette année là - ça date un peu
tout ça - t'as un ISBN ?

[...] pour t'amuser, tu es libre de faire tout ce que tu veux []


je viens philosopher avec toi pour cela ;)

Sylvain.



Avatar
James Kanze
On Jul 5, 11:41 am, "Ael Rowan Terence" wrote:

[...]
Pour l'aspect temps d'execution, cela, à priori, me semble faux.
Et une vérification s'impose.


En effet, tant qu'on ne l'a pas vérifé, on ne sait pas.
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. En général, c'est une
perte de temps d'y penser avant que le profiler en a montré la
nécessité.

Et en passant, ne sois pas étonné si tes attentes soient
trompées. Je me rappelle avoir fait des mesures avec
std::string, et au moins avec l'implémentation g++ à l'époque,
c'était plus rapide de créer une chaîne nouvelle chaque fois
dans la boucle que de réutiliser une chaîne définie en dehors de
la boucle.

Enfin, note bien qu'il peut y avoir de légères différences de
sémantique. Que la réinitialisation avec une chaîne nouvelle ne
libère pas la mémoire, par exemple. (Qui peut être un avantage
parfois. Ou non, selon le cas.)

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

Avatar
James Kanze
On Jul 5, 1:26 pm, "Ael Rowan Terence" wrote:

[...]
Quant à James, est-il vraiment nécessaire que je justifie
pourquoi le seul __ oss.str("")__ , suffit pour resourdre ma
problématique.


S'il resoud ta problématique, sans y présenter des désavantages,
pourquoi pas. Je ne connais pas ta problématique ; je ne peux
donc pas juger. Ce que je sais, c'est que bien trop souvent, on
essaie de réutiliser des flux (particulièrement des
stringstream) quand ce qu'on veut réelement, c'est un nouveau
flux. Ce qui ne va pas sans problèmes, dont le premier c'est que
c'est moins transparent au lecteur, qui se pose la question :
de quoi a-i-il besoin dans cet ancien flux, qui fait qu'il ne
prend pas un nouveau ?

En fin de compte, c'est Alain qui a compris le sens de mon
intervention. C'est de faire reflechir. La solution « par
defaut », c'est le nouveau flux. Il y a parfois des raisons
pour s'écarter de la solution par defaut, mais il faut bien
comprendre alors pourquoi on le fait -- écarter d'une solution
« standard » doit être une demarche motivée.

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