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.
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.
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.
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 cap acité
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 nom bre
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 ??
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!
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 pouvo ir
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 pouv ant
ê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 conditionnelleme nt
injecté dans le flux principal.
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 cap acité
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 nom bre
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 ??
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!
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 pouvo ir
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 pouv ant
ê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 conditionnelleme nt
injecté dans le flux principal.
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 cap acité
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 nom bre
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 ??
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!
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 pouvo ir
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 pouv ant
ê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 conditionnelleme nt
injecté dans le flux principal.
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éth ode
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 fai re
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 e t son
corrolaire nécessaire que les autres sont des imbéciles.
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éth ode
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 fai re
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 e t son
corrolaire nécessaire que les autres sont des imbéciles.
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éth ode
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 fai re
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 e t son
corrolaire nécessaire que les autres sont des imbéciles.
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.
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.
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.
La règle donc, c'est d'abord d'écrire le code le plus
simplement et le plus clairement possible ; plus c'est simple,
et plus c'est clair, plus il serait facile d'effectuer n'importe
quelle modification qui s'avère nécessaire par la suite.
Je ne voulais pas critiquer Ael Rowen ; je ne sais pas dans
quel but il veut « effacer ».
La règle donc, c'est d'abord d'écrire le code le plus
simplement et le plus clairement possible ; plus c'est simple,
et plus c'est clair, plus il serait facile d'effectuer n'importe
quelle modification qui s'avère nécessaire par la suite.
Je ne voulais pas critiquer Ael Rowen ; je ne sais pas dans
quel but il veut « effacer ».
La règle donc, c'est d'abord d'écrire le code le plus
simplement et le plus clairement possible ; plus c'est simple,
et plus c'est clair, plus il serait facile d'effectuer n'importe
quelle modification qui s'avère nécessaire par la suite.
Je ne voulais pas critiquer Ael Rowen ; je ne sais pas dans
quel but il veut « effacer ».
