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.
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.
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.
Quant à James, est-il vraiment nécessaire que je justifie
pourquoi le seul __ oss.str("")__ , suffit pour resourdre ma
problématique.
Je ne connais pas ta problématique ; je ne peux
donc pas juger.
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.
Quant à James, est-il vraiment nécessaire que je justifie
pourquoi le seul __ oss.str("")__ , suffit pour resourdre ma
problématique.
Je ne connais pas ta problématique ; je ne peux
donc pas juger.
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.
Quant à James, est-il vraiment nécessaire que je justifie
pourquoi le seul __ oss.str("")__ , suffit pour resourdre ma
problématique.
Je ne connais pas ta problématique ; je ne peux
donc pas juger.
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.
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é.
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é.
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é.
"James Kanze" a écrit dans le message de
news:
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é.
Donc, toi aussi, tu t'inscris en faux sur l'affirmation de "Christophe
Lephay "
<Citation>
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.
<Citation/>
En tout cas elle n'est pas vrai dans tous les cas de figure sur l'aspect
"temps d'exécution".
"James Kanze" <james.kanze@gmail.com> a écrit dans le message de
news:1183708702.435308.286660@r34g2000hsd.googlegroups.com...
On Jul 5, 11:41 am, "Ael Rowan Terence" <N...@Null.fr> 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é.
Donc, toi aussi, tu t'inscris en faux sur l'affirmation de "Christophe
Lephay "
<Citation>
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.
<Citation/>
En tout cas elle n'est pas vrai dans tous les cas de figure sur l'aspect
"temps d'exécution".
"James Kanze" a écrit dans le message de
news:
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é.
Donc, toi aussi, tu t'inscris en faux sur l'affirmation de "Christophe
Lephay "
<Citation>
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.
<Citation/>
En tout cas elle n'est pas vrai dans tous les cas de figure sur l'aspect
"temps d'exécution".
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é in jecté.
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 ri en
à cela.
mais l'approche (jouée sous la forme d'argument d'autorité, pardon po ur
la redite) cela est impossible (en général, et pas que pour cette
implémentation là) parce que nécessairement l'abstraction fondament ale
... 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émentati on
concrête d'un type de flux particulier peut trouver des réponses
(spécialisations) évidentes et pertinentes pour ce flux (comme défi nir
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 à s on
é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.
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 t exte
à formatter. si je génére un DER, je ne vais pas (systématiquemen t) me
taper une méthode pour encoder chaque data object.
je viens philosopher avec toi pour cela ;)
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é in jecté.
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 ri en
à cela.
mais l'approche (jouée sous la forme d'argument d'autorité, pardon po ur
la redite) cela est impossible (en général, et pas que pour cette
implémentation là) parce que nécessairement l'abstraction fondament ale
... 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émentati on
concrête d'un type de flux particulier peut trouver des réponses
(spécialisations) évidentes et pertinentes pour ce flux (comme défi nir
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 à s on
é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.
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 t exte
à formatter. si je génére un DER, je ne vais pas (systématiquemen t) me
taper une méthode pour encoder chaque data object.
je viens philosopher avec toi pour cela ;)
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é in jecté.
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 ri en
à cela.
mais l'approche (jouée sous la forme d'argument d'autorité, pardon po ur
la redite) cela est impossible (en général, et pas que pour cette
implémentation là) parce que nécessairement l'abstraction fondament ale
... 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émentati on
concrête d'un type de flux particulier peut trouver des réponses
(spécialisations) évidentes et pertinentes pour ce flux (comme défi nir
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 à s on
é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.
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 t exte
à formatter. si je génére un DER, je ne vais pas (systématiquemen t) me
taper une méthode pour encoder chaque data object.
je viens philosopher avec toi pour cela ;)
"Ael Rowan Terence" a écrit dans le message de news:
f6l03c$6ar$"James Kanze" a écrit dans le message de
news:
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é.
Donc, toi aussi, tu t'inscris en faux sur l'affirmation de "Christophe
Lephay "
<Citation>
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.
<Citation/>
En tout cas elle n'est pas vrai dans tous les cas de figure sur l'aspect
"temps d'exécution".
Il dit que :
1- On ne peut rien affirmer tant qu'on n'a pas testé, et il se peut que
cela
change d'une implémentation à l'autre ;
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.
Dans tous les cas, il vaut mieux se méfier des idées reçues, et ce serait
une mauvaise idée de ne pas vouloir créer un nouveau flux sous pretexte
d'économiser de quelconques ressources, dont le temps d'exécution.
C'est pourquoi j'avais parlé du temps d'exécution, même s'il y manquait
sans doute
les réserves d'usage.
Je ne sais pas s'il s'inscrit en faux à proprement parler dans la mesure
où
il cite un exemple avec une string pour laquelle la création d'une
nouvelle
était plus rapide.
"Ael Rowan Terence" <Nul@Null.fr> a écrit dans le message de news:
f6l03c$6ar$1@news1.completel.net...
"James Kanze" <james.kanze@gmail.com> a écrit dans le message de
news:1183708702.435308.286660@r34g2000hsd.googlegroups.com...
On Jul 5, 11:41 am, "Ael Rowan Terence" <N...@Null.fr> 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é.
Donc, toi aussi, tu t'inscris en faux sur l'affirmation de "Christophe
Lephay "
<Citation>
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.
<Citation/>
En tout cas elle n'est pas vrai dans tous les cas de figure sur l'aspect
"temps d'exécution".
Il dit que :
1- On ne peut rien affirmer tant qu'on n'a pas testé, et il se peut que
cela
change d'une implémentation à l'autre ;
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.
Dans tous les cas, il vaut mieux se méfier des idées reçues, et ce serait
une mauvaise idée de ne pas vouloir créer un nouveau flux sous pretexte
d'économiser de quelconques ressources, dont le temps d'exécution.
C'est pourquoi j'avais parlé du temps d'exécution, même s'il y manquait
sans doute
les réserves d'usage.
Je ne sais pas s'il s'inscrit en faux à proprement parler dans la mesure
où
il cite un exemple avec une string pour laquelle la création d'une
nouvelle
était plus rapide.
"Ael Rowan Terence" a écrit dans le message de news:
f6l03c$6ar$"James Kanze" a écrit dans le message de
news:
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é.
Donc, toi aussi, tu t'inscris en faux sur l'affirmation de "Christophe
Lephay "
<Citation>
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.
<Citation/>
En tout cas elle n'est pas vrai dans tous les cas de figure sur l'aspect
"temps d'exécution".
Il dit que :
1- On ne peut rien affirmer tant qu'on n'a pas testé, et il se peut que
cela
change d'une implémentation à l'autre ;
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.
Dans tous les cas, il vaut mieux se méfier des idées reçues, et ce serait
une mauvaise idée de ne pas vouloir créer un nouveau flux sous pretexte
d'économiser de quelconques ressources, dont le temps d'exécution.
C'est pourquoi j'avais parlé du temps d'exécution, même s'il y manquait
sans doute
les réserves d'usage.
Je ne sais pas s'il s'inscrit en faux à proprement parler dans la mesure
où
il cite un exemple avec une string pour laquelle la création d'une
nouvelle
était plus rapide.
Mais ma demande n'etait pas celle-là.
Et je ne veux pas me laisser entrainer dans un debat philosophique sur un
point qu'il ne peut accepter : c-a-d l'utilisation de oss.str("")
Mais ma demande n'etait pas celle-là.
Et je ne veux pas me laisser entrainer dans un debat philosophique sur un
point qu'il ne peut accepter : c-a-d l'utilisation de oss.str("")
Mais ma demande n'etait pas celle-là.
Et je ne veux pas me laisser entrainer dans un debat philosophique sur un
point qu'il ne peut accepter : c-a-d l'utilisation de oss.str("")
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 ?
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 ?
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 ?
"Christophe Lephay" 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.
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.
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.
une mauvaise idée de ne pas vouloir créer un nouveau flux sous pretexte
d'économiser de quelconques ressources, dont le temps d'exécution.
C'est ce que je nommerai une affirmation à l'emporte piece.
Plus précisément : affirmation à l'emporte piece ex-nihilo.
Je ne me rappelle qui que soit pretendant economiser un ressource en
s'évitant la création d'un flux.
C'est pourquoi j'avais parlé du temps d'exécution, même s'il y manquait
sans douteles réserves d'usage.
C'est donc ça ... les "reserves d'usages".
"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.
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.
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.
une mauvaise idée de ne pas vouloir créer un nouveau flux sous pretexte
d'économiser de quelconques ressources, dont le temps d'exécution.
C'est ce que je nommerai une affirmation à l'emporte piece.
Plus précisément : affirmation à l'emporte piece ex-nihilo.
Je ne me rappelle qui que soit pretendant economiser un ressource en
s'évitant la création d'un flux.
C'est pourquoi j'avais parlé du temps d'exécution, même s'il y manquait
sans doute
les réserves d'usage.
C'est donc ça ... les "reserves d'usages".
"Christophe Lephay" 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.
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.
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.
une mauvaise idée de ne pas vouloir créer un nouveau flux sous pretexte
d'économiser de quelconques ressources, dont le temps d'exécution.
C'est ce que je nommerai une affirmation à l'emporte piece.
Plus précisément : affirmation à l'emporte piece ex-nihilo.
Je ne me rappelle qui que soit pretendant economiser un ressource en
s'évitant la création d'un flux.
C'est pourquoi j'avais parlé du temps d'exécution, même s'il y manquait
sans douteles réserves d'usage.
C'est donc ça ... les "reserves d'usages".
Mais ma demande n'etait pas celle-là.
Et je ne veux pas me laisser entrainer dans un debat philosophique sur
un
point qu'il ne peut accepter : c-a-d l'utilisation de oss.str("")
S'il ne peut l'accepter, c'est parce qu'il a de bonnes raisons.
Et ce que tu devrais conclure c'est qu'il y a un problème de fond dans ta
demande.
Mais bon on est dans un pays libre, donc libre à toi de t'entêter :)
Mais ma demande n'etait pas celle-là.
Et je ne veux pas me laisser entrainer dans un debat philosophique sur
un
point qu'il ne peut accepter : c-a-d l'utilisation de oss.str("")
S'il ne peut l'accepter, c'est parce qu'il a de bonnes raisons.
Et ce que tu devrais conclure c'est qu'il y a un problème de fond dans ta
demande.
Mais bon on est dans un pays libre, donc libre à toi de t'entêter :)
Mais ma demande n'etait pas celle-là.
Et je ne veux pas me laisser entrainer dans un debat philosophique sur
un
point qu'il ne peut accepter : c-a-d l'utilisation de oss.str("")
S'il ne peut l'accepter, c'est parce qu'il a de bonnes raisons.
Et ce que tu devrais conclure c'est qu'il y a un problème de fond dans ta
demande.
Mais bon on est dans un pays libre, donc libre à toi de t'entêter :)