ostringstream effacer

Sylvain wrote:

James Kanze wrote on 03/07/2007 09:26:

hmmm, ça a un rapport avec le non gaspillage des ressources et le
développement (informatique) durable ?

Tu pourrais préciser plus clairement, parce que je ne vois pas
de rapport. Si tu veux un nouveau flux, essayer d'en rémodeler
un ancien me semble un gaspillage énorme de la ressource la plus
rare : le temps de développement. Avec en plus rien en retour
(sauf peut-être des emmerdes).

très clairement ?

le PO n'évoque pas la création d'un *nouveau* flux (que l'on pourra
envisager comme différent), mais demande à "effacer le contenu" coura nt.

Il a parlé d'« effacer », sans préciser quoi. D'un sens réel,
un flux n'a pas de contenu ; il s'apparente plus à un itérateur
qu'à une collection.

personne n'a donc jamais imaginé "remodeler" mais seulement
"remettre à son état initial";

Ce qui n'est réelement possible qu'en construisant une nouvelle
instance. Toute la question est là, en fait : pourquoi une
nouvelle instance ne lui convient pas ?

voulais-tu indiquer que le temps de développement des
créateurs de ostringstream est si précieux qu'ils n'ont pas voulu le
gaspiller à imaginer un simple "reset()" ?

Je crois que c'est plutôt qu'ils n'en ont pas vu l'intérêt. Moi
non plus, d'ailleurs -- c'est pour ça que je démande ce qu'il
cherche à faire. (Note bien que même les collections n'ont pas
de reset(). En général, je crois, la philosphie est : si tu
veux un objet à l'état neuf, tu n'as qu'à prendre un objet
neuf.)

plus généralement - mais je vais glisser ici dans le 100% HS, HC - la
méthode y-a-jeter-et-reconsommer qui a été suggérée est, à me s yeux, un
biais introduit par la tendance "naturelle" (?) à la consommation sans
gestion des ressources.

La consommation sans gestion de quelles ressources ? J'avoue ne
pas arriver à comprendre ce qui te gène.

je travaille (plus ou moins comme toi) dans des équipes R&D de
dévloppements logiciels (et France et ailleurs) depuis suffisament
d'années pour savoir comment le si précieux temps de développement est
de toute façon gaspillée dans une étape ou une autre, dès lors ton
anathème me parait largement hors de propos.

En somme, tu es contre l'efficacité, et pour la création des
emplois bidons qui ne servent à rien. (Pourquoi n'utiliser que
deux ingenieurs pendant six mois, quand on peut en occuper dix
pendant deux ans ?)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
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 wrote on 04/07/2007 09:11:

le PO n'évoque pas la création d'un *nouveau* flux (que l'on pourra
envisager comme différent), mais demande à "effacer le contenu" courant.

Il a parlé d'« effacer », sans préciser quoi.

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

donc il précise, implicitement, qu'il ne veux pas effacer (invalider,
changer, ...) des attributs de formatages, mais bien un *"contenu"*,
chacun sachant que le contenu d'un string_stream étant des (bouts de)
strings, chacun peut comprendre qu'il souhaite effacer (virer, oublier,
...) les bouts de strings qui auraient été accumulées dans ce flux.

maintenant si "effacer le contenu" ne veux pas dire "effacer le contenu"
pour le plaisir de s'entêter et d'avoir raison... tu as sûrement raison.

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

personne n'a donc jamais imaginé "remodeler" mais seulement
"remettre à son état initial";

Ce qui n'est réelement possible qu'en construisant une nouvelle
instance.

tu veux dire pour une implémentation qui impose cela.

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.

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.

une classe / un opérateur dont le seul but serait d'accumuler /
formatter des données *temporaires* en vue d'un transfert vers un flux
différent de l'objet lui-même (par exemple quelque chose injectant un
record dans une table SQL) peut naturellement se concevoir (l'exemple
SQL vient de mon expérience immédiate) pour autant je parlerais ici de
formatteur ou simplement d'injecteur mais pas de flux (le flux étant un
contenu ET des opérateurs d'injection).

Toute la question est là, en fait : pourquoi une
nouvelle instance ne lui convient pas ?

cela ne me convient pas non plus, et simplement parce que je
n'imaginerais jamais coder qlq chose comme:

xxxxxStream stream;
.....
xxxxxStream unAutreStream;
.....
xxxxxStream encoreUnAutreStream;
.....

quand je peux coder

xxxxxStream stream;
.....
stream.empty();
.....
stream.empty();
.....

voulais-tu indiquer que le temps de développement des
créateurs de ostringstream est si précieux qu'ils n'ont pas voulu le
gaspiller à imaginer un simple "reset()" ?

Je crois que c'est plutôt qu'ils n'en ont pas vu l'intérêt. Moi
non plus, d'ailleurs -- c'est pour ça que je démande ce qu'il
cherche à faire. (Note bien que même les collections n'ont pas
de reset().

"Les" ?? les miennes ont toutes une méthode "empty()" (en fait
releaseAll() et deleteAll()).

plus généralement - mais je vais glisser ici dans le 100% HS, HC - la
méthode y-a-jeter-et-reconsommer qui a été suggérée est, à mes yeux, un
biais introduit par la tendance "naturelle" (?) à la consommation sans
gestion des ressources.

La consommation sans gestion de quelles ressources ? J'avoue ne
pas arriver à comprendre ce qui te gène.

ce qui me gène est l'argument d'autorité "il faut faire ainsi (utiliser
une nouvelle instance) car toute autre démarche serait un gaspillage du
temps si précieux qui coute si cher".

si pipeau n'a de sens que si on accepte également sans discussion un
paquet de règles économico-comportementales tout aussi dogmatiques.
ce forum n'est pas le lieu pour un ouvrir un gélatineux chapitre 21
appliqué au développement; je me limite donc à mon point précédent.

je travaille (plus ou moins comme toi) dans des équipes R&D de
dévloppements logiciels (et France et ailleurs) depuis suffisament
d'années pour savoir comment le si précieux temps de développement est
de toute façon gaspillée dans une étape ou une autre, dès lors ton
anathème me parait largement hors de propos.

En somme, tu es contre l'efficacité, et pour la création des
emplois bidons qui ne servent à rien. (Pourquoi n'utiliser que
deux ingenieurs pendant six mois, quand on peut en occuper dix
pendant deux ans ?)

?? et tu as lu ça où ????

dois-je en conclure à mon tour que, en somme, tu es contre l'efficacité,
et pour la création des baignoires bidons qui ne servent à rien.
(Pourquoi n'utiliser que deux robients pendant six minutes, quand on
peut en occuper dix pendant deux heures ?) - et bien je ne te facilite pas !

Sylvain.

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

James Kanze wrote on 04/07/2007 09:11:

le PO n'évoque pas la création d'un *nouveau* flux (que l'on pourra
envisager comme différent), mais demande à "effacer le contenu" courant.

Il a parlé d'« effacer », sans préciser quoi.

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

donc il précise, implicitement, qu'il ne veux pas effacer (invalider,
changer, ...) des attributs de formatages, mais bien un *"contenu"*,
chacun sachant que le contenu d'un string_stream étant des (bouts de)
strings, chacun peut comprendre qu'il souhaite effacer (virer, oublier,
...) les bouts de strings qui auraient été accumulées dans ce flux.

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.

Ce qui n'est réelement possible qu'en construisant une nouvelle
instance.

tu veux dire pour une implémentation qui impose cela.

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.

Il est question des classes de la SL, pas de tes propres classes.

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.

Si c'est avant tout le contenu, autant utiliser directement un string plutôt
qu'un stringstream.

Je crois que c'est plutôt qu'ils n'en ont pas vu l'intérêt. Moi
non plus, d'ailleurs -- c'est pour ça que je démande ce qu'il
cherche à faire. (Note bien que même les collections n'ont pas
de reset().

"Les" ?? les miennes ont toutes une méthode "empty()" (en fait
releaseAll() et deleteAll()).

On parle des flux standards. Si leurs concepteurs n'ont pas créé de méthode
comme les tiennes, il est probable que ce n'est pas un oubli mais qu'ils
l'ont fait pour une raison que tu as l'air d'ignorer.

La consommation sans gestion de quelles ressources ? J'avoue ne
pas arriver à comprendre ce qui te gène.

ce qui me gène est l'argument d'autorité "il faut faire ainsi (utiliser
une nouvelle instance) car toute autre démarche serait un gaspillage du
temps si précieux qui coute si cher".

Ce n'est pas un argument d'autorité. James a expliqué en quoi le seul fait
d'effacer la strinf était susceptible de poser problème.

si pipeau n'a de sens que si on accepte également sans discussion un
paquet de règles économico-comportementales tout aussi dogmatiques.
ce forum n'est pas le lieu pour un ouvrir un gélatineux chapitre 21
appliqué au développement; je me limite donc à mon point précédent.

Ce chapitre, c'est toi qui l'a ouvert en venant parler d'un développement
durable dont on se demande bien ce que ça vient foutre ici.

dois-je en conclure à mon tour que, en somme, tu es contre l'efficacité,
et pour la création des baignoires bidons qui ne servent à rien. (Pourquoi
n'utiliser que deux robients pendant six minutes, quand on peut en occuper
dix pendant deux heures ?) - et bien je ne te facilite pas !

Sauf que la création d'un nouveau flux est à la fois plus rapide en temps de
développement, en temps d'exécution, et plus fiable. Il y a généralement
moyen de coder de manière à ce que le flux ne soit désigner que par un seul
nom (en le créant dans le corps d'une boucle, par exemple).

Christophe Lephay wrote on 04/07/2007 20:16:

Chacun peut comprendre ce qu'il veut.

toutafai, d'ailleurs sur tes points ci-après ...

[...]

Sauf que la création d'un nouveau flux est à la fois plus rapide en temps de
développement, en temps d'exécution, et plus fiable. Il y a généralement
moyen de coder de manière à ce que le flux ne soit désigner que par un seul
nom (en le créant dans le corps d'une boucle, par exemple).

j'ai bien fait de lire jusqu'au bout; merci pour cette puissance astuce
pleine de rapidité en temps de dévelopment, en temps d'éxécution et en
fiabilité!

Sylvain.

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

j'ai bien fait de lire jusqu'au bout; merci pour cette puissance astuce
pleine de rapidité en temps de dévelopment, en temps d'éxécution et en
fiabilité!

"L'ironie est un génie qui dispense de tous les autres, de cour et de bon
sens".

T'es pas obligé d'être agressif, tu sais...

On Jul 4, 7:25 pm, Sylvain <noS...@mail.net> wrote:

James Kanze wrote on 04/07/2007 09:11:

le PO n'évoque pas la création d'un *nouveau* flux (que l'on pourra
envisager comme différent), mais demande à "effacer le contenu" co urant.

Il a parlé d'« effacer », sans préciser quoi.

tu n'as pas le même post que moi ? pour ma part je lis "Quelle procéd ure
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.

donc il précise, implicitement, qu'il ne veux pas effacer (invalider,
changer, ...) des attributs de formatages, mais bien un *"contenu"*,
chacun sachant que le contenu d'un string_stream étant des (bouts de)
strings, chacun peut comprendre qu'il souhaite effacer (virer, oublier,
...) les bouts de strings qui auraient été accumulées dans ce flux.

Il n'a rien précisé. Il a posté une question vague. Avant de
répondre, je préfère qu'il précise, justement.

maintenant si "effacer le contenu" ne veux pas dire "effacer
le contenu" pour le plaisir de s'entêter et d'avoir raison...
tu as sûrement raison.

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

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é injec té.

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

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.

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 sou rce
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.

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.

personne n'a donc jamais imaginé "remodeler" mais seulement
"remettre à son état initial";

Ce qui n'est réelement possible qu'en construisant une nouvelle
instance.

tu veux dire pour une implémentation qui impose cela.

Je veux dire que selon la définition actuelle du langage.

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

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.

Toute la question est là, en fait : pourquoi une
nouvelle instance ne lui convient pas ?

cela ne me convient pas non plus, et simplement parce que je
n'imaginerais jamais coder qlq chose comme:

xxxxxStream stream;
.....
xxxxxStream unAutreStream;
.....
xxxxxStream encoreUnAutreStream;
.....

quand je peux coder

xxxxxStream stream;
.....
stream.empty();
.....
stream.empty();
.....

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 :

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

contre :

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

Or, j'ai du mal à voir comment on pourrait préférer le premier.

voulais-tu indiquer que le temps de développement des
créateurs de ostringstream est si précieux qu'ils n'ont pas voulu le
gaspiller à imaginer un simple "reset()" ?

Je crois que c'est plutôt qu'ils n'en ont pas vu l'intérêt. Moi
non plus, d'ailleurs -- c'est pour ça que je démande ce qu'il
cherche à faire. (Note bien que même les collections n'ont pas
de reset().

"Les" ?? les miennes ont toutes une méthode "empty()" (en fait
releaseAll() et deleteAll()).

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.

plus généralement - mais je vais glisser ici dans le 100% HS, HC - la
méthode y-a-jeter-et-reconsommer qui a été suggérée est, à mes yeux, un
biais introduit par la tendance "naturelle" (?) à la consommation sa ns
gestion des ressources.

La consommation sans gestion de quelles ressources ? J'avoue ne
pas arriver à comprendre ce qui te gène.

ce qui me gène est l'argument d'autorité "il faut faire ainsi (utilis er
une nouvelle instance) car toute autre démarche serait un gaspillage du
temps si précieux qui coute si cher".

L'argument, ce n'est pas « il faut faire ainsi ». L'argument,
c'est qu'il faut savoir exactement ce qu'on veut faire, et
écrire le code le plus simple et le plus sûr qui le fait.

si pipeau n'a de sens que si on accepte également sans discussion un
paquet de règles économico-comportementales tout aussi dogmatiques.

Il y a bien une ontologie professionnelle, non ? Un ingenieur
n'a pas un comportement irrationnel. Il travaille pour
quelqu'un, et il a un certain nombre de responsibilités
vis-à-vis son employeur. Que tu programmes chez toi, pour
t'amuser, tu es libre de faire tout ce que tu veux ; si le but,
c'est de s'amuser, la meilleur façon de programmer, c'est celle
qui t'amuse le plus. Si tu es employé comme ingenieur en
informatique, l'ontologie professionnelle fait que la meilleur
façon de programmer, c'est celle qui avance les intérêts
(économiques, prèsque toujours) de ton employeur. (Dans
certaines limites, évidemment. On a aussi des responsibilités
vis-à-vis la société.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
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" <james.kanze@gmail.com> a écrit dans le message de
news:1183484188.098976.234740@k29g2000hsd.googlegroups.com...
On Jul 3, 3:49 pm, "Ael Rowan Terence" <N...@Null.fr> wrote:

"James Kanze" <james.ka...@gmail.com> a écrit dans le message
denews:1183469186.313483.80520@w5g2000hsg.googlegroups.com...

On Jul 3, 11:02 am, "Ael Rowan Terence" <N...@Null.fr> wrote:

Mais ça veut dire quoi, effacer un ostringstream ?

oss << "toto" ;
[....]
oss << "+"
[....]
oss << "titi" ;
[....]

// effacer >> oss .str ("") ;

Ce n'est pas vraiment ce que j'entends par « effacer », mais

Soit, tu entends autre chose.
Une réponse, apportée par Cyrille, me convient parfaitement.

ce n'était pas ma question. Ma question, c'est ce que tu
entendais par effacer. Remettre à son état initial ? Vider la
chaîne, sans changer quoique ce soit d'autre ? Vider la chaîne
et en libérer la mémoire qui lui est associée ?

On efface les éléments dans une collection, parce que la norme a
choisi ce mot (l'anglais « erase ») pour le faire, mais même
là, je trouve qu'il ne convient pas réelement. Par extension,
dans un flux, on pourrait effacer le contenu (mais en général,
ce n'est pas supporter), l'état (plus d'erreur), les paramètres
du formattage, la liaison avec le streambuf, etc., etc. Un flux,
c'est plus complexe qu'une collection, et il y a beaucoup de
choses qu'on pourrait y effacer. Et dans un sens réel, les
données qu'on y a écrit n'en font pas partie ; une fois
écrites, elles sont ailleurs. C'est l'abstraction d'un flux.

Je veux juste, grosso modo, l'utiliser quasiment aussi
simplement que l'exemple donné plus haut.

Dans quel but, c'est ça ma question. Pourquoi est-ce que
l'utilisation d'un nouveau flux ne te convient pas ? C'est
quand même la solution « naturelle ».

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.
Et je te remercie de m'avoir indiqué une autre solution, et pour les pieges
que la solution que j'utilise recelle.

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

James Kanze wrote on 04/07/2007 09:11:

le PO n'évoque pas la création d'un *nouveau* flux (que l'on pourra
envisager comme différent), mais demande à "effacer le contenu"
courant.

Il a parlé d'« effacer », sans préciser quoi.

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

donc il précise, implicitement, qu'il ne veux pas effacer (invalider,
changer, ...) des attributs de formatages, mais bien un *"contenu"*,
chacun sachant que le contenu d'un string_stream étant des (bouts de)
strings, chacun peut comprendre qu'il souhaite effacer (virer, oublier,
...) les bouts de strings qui auraient été accumulées dans ce flux.

Merci, Sylvain, c'est bien cela.

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

Chacun peut comprendre ce qu'il veut.

Ha bon ! mais alors à quoi sert de discuter, si chacun ne veut "comprendre
que ce qu'il veut" ?

Ce n'est pas un argument d'autorité. James a expliqué en quoi le seul fait
d'effacer la strinf était susceptible de poser problème.

Ca, c'est ce que tu veux comprendre ?
D'autres l'ont compris différement.

Ce chapitre, c'est toi qui l'a ouvert en venant parler d'un développement
durable dont on se demande bien ce que ça vient foutre ici.

Hou là là, ca devient agressif.
Serait-il interdit d'exposer ses points de vue sur ce forum ?

Sauf que la création d'un nouveau flux est à la fois plus rapide en temps
de

développement, en temps d'exécution, et plus fiable. Il y a généralement
moyen de coder de manière à ce que le flux ne soit désigner que par un
seul

nom (en le créant dans le corps d'une boucle, par exemple).

Pour l'aspect temps de développement, c'est ok.
Pour l'aspect temps d'execution, cela, à priori, me semble faux.
Et une vérification s'impose.

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

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

j'ai bien fait de lire jusqu'au bout; merci pour cette puissance astuce
pleine de rapidité en temps de dévelopment, en temps d'éxécution et en
fiabilité!

"L'ironie est un génie qui dispense de tous les autres, de cour et de bon
sens".

T'es pas obligé d'être agressif, tu sais...

C'est bizarre j'ai l'impression que tu reproches à Sylvain ton propre
travers.