passer une liste d'argument variable lors d'un appel

Sylvain wrote:

James Kanze wrote on 09/04/2006 20:35:

si l'error handler en question ne fait qu'écrire
l'information reçue dans un fichier (stream, console,
...), cela peut fonctionner.

mais, même dans ce cas, si le gestionnaire d'erreur va
jusqu'à arrêter l'application (selon la sévérité de
l'erreur) seul le premier argument sera enregistré.

Pas chez moi. Au moins, pas avec la forme avec des <<.

mais pas chez moi non plus mon brave monsieur!

Alors, qu'est-ce que tu essayais à dire quand tu disais que seul
le premier argument sera enregistré.

non pas que je réserve l'instruction:
errorHdlr << "monTrucVachementPropreQuiSertAFlusher";
pour réaliser le traitement (vs la mise en tampon), mais juste
que c'est trop grotesque pour que je l'imagine.

Mais je n'ai pas de truc (explicit, en tout cas) pour déclencher
le flush. J'exploite la durée de vie des temporaires, pour que
le tout soit transparent à l'utilisateur.

si, pour un autre mode, la méthode affiche un dialogue
d'alerte, cela va être un peu moins efficace (une alerte
par argument!) (à moins de recompliquer arbitrairement le
gestionnaire avec des inputters muets et un flusher
bavard).

Encore une fois -- pas chez moi. Évidemment, dans mes
applications, il n'y a pas de dialogue d'alerte, parce que
normalement, il n'y a pas de terminal affecté au programme,
mais j'envoie bien des emails et d'autres choses semblables.

je n'en doute pas un instant! j'ai bien vu des codes se
connectant sur une base, locker N tables, écrire *un* octet,
delocker le bouzin, perdre la connection, ..., pour chaque
octet injecté; donc je ne m'étonnerai de rien.

Si tu écris des choses comme ça, c'est ton problème. Ça laisse
trainer des doutes sur ta compréhension de la gestion des
threads, mais tu ne serais pas le premier à faire ce genre de
bêtise.

en ce qui concerne la duplication du code -- les templates
sont là pour ça.

excellente celle-là !! merci ! je la note en tête des
histoires droles.

Je ne comprends pas. Je n'ai pas de duplication du code, parce
que je me suis servi des templates. C'est une technique connue
et approuvée par ceux qui connaissent le C++.

--
James Kanze GABI Software
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

kanze wrote on 11/04/2006 11:44:

mais, même dans ce cas, si le gestionnaire d'erreur va
jusqu'à arrêter l'application (selon la sévérité de
l'erreur) seul le premier argument sera enregistré.

Pas chez moi. Au moins, pas avec la forme avec des <<.

mais pas chez moi non plus mon brave monsieur!

Alors, qu'est-ce que tu essayais à dire quand tu disais que seul
le premier argument sera enregistré.

je n'ai pas "essayé de dire" ... mais as-tu essayé de comprendre?

non pas que je réserve l'instruction:
errorHdlr << "monTrucVachementPropreQuiSertAFlusher";
pour réaliser le traitement (vs la mise en tampon), mais juste
que c'est trop grotesque pour que je l'imagine.

Mais je n'ai pas de truc (explicit, en tout cas) pour déclencher
le flush. J'exploite la durée de vie des temporaires, pour que
le tout soit transparent à l'utilisateur.

ah les temporaires, un bon flush masqué dans un destructeur, j'ai bon
Monsieur devinette ?

mais alors, ton post précédent était:

Pas chez moi. Au moins, pas avec la forme avec des <<.

peux-tu nous expliquer pourquoi ton destructeur serait géné par une
méthode (T& arg(X x)) et ne le serait pas par un opérateur << ??

dans le même temps, peux-tu nous expliquer comment loguer *une* fois la
même erreur survenue dans X (64, 128, ...) threads lancés simultanément
mais échouant tous pour la même raison (extérieure aux threads).

peux-tu également indiquer où placer ton temporaire dans une chaine
d'appels de méthodes (le C++ est procédurale, non?) d'où on sort par des
catch / throw en cascade ?

je n'en doute pas un instant! j'ai bien vu des codes se
connectant sur une base, locker N tables, écrire *un* octet,
delocker le bouzin, perdre la connection, ..., pour chaque
octet injecté; donc je ne m'étonnerai de rien.

Si tu écris des choses comme ça, c'est ton problème. Ça laisse
trainer des doutes sur ta compréhension de la gestion des
threads, mais tu ne serais pas le premier à faire ce genre de
bêtise.

où as-tu lu que *j* 'écrivais des choses comme ça ?
quel rapport cela a-t-il avec des threads ?

en ce qui concerne la duplication du code -- les templates
sont là pour ça.

excellente celle-là !! merci ! je la note en tête des
histoires droles.

Je ne comprends pas.

ben désolé alors.

Je n'ai pas de duplication du code, parce que je me
suis servi des templates. C'est une technique connue
et approuvée par ceux qui connaissent le C++.

non, ceux qui connaissent le C++ savent que "déclarer" et "instancier"
une classe template "duplique" le code template en code concrêt; le
binaire ne contient (évidemment) pas la classe de définition mais autant
de code (dupliqué au type classe paramètre) que de classes générées.

cela t'aurait échapper ?

Sylvain.

Sylvain wrote:

Je n'ai pas de duplication du code, parce que je me
suis servi des templates. C'est une technique connue
et approuvée par ceux qui connaissent le C++.

non, ceux qui connaissent le C++ savent que "déclarer" et "instancier"
une classe template "duplique" le code template en code concrêt; le
binaire ne contient (évidemment) pas la classe de définition mais autant
de code (dupliqué au type classe paramètre) que de classes générées.

cela t'aurait échapper ?

Dites, ça vous dirait pas de vous calmer un peu. Parce que dire
n'importe quoi en agressant les autres et en prenant tout le monde pour
des imbéciles, ce n'est pas bien passionnant. Chercher absolument la
manière d'interprèter ce que dit l'autre de manière à que ce puisse être
faux au lieu de chercher à comprendre ce qu'il dit, c'est aussi très
pénible.

En l'occurrence, l'intérêt d'éviter la duplication de code, c'est
essentiellement pour la maintenance. Un code dupliqué (au niveau des
sources) pose des problèmes de maintenance si une erreur est corrigé
dans une des parties dupliquées et pas dans une autre.

Les templates permettent d'éviter la duplication de code... source.
J'imagine que c'est ce dont parlait James.

En revanche, je ne saisis pas le problème d'avoir du code binaire
dupliqué ? C'est par soucis de la taille de l'exécutable ?
--
Arnaud

Arnaud Meurgues wrote on 11/04/2006 23:53:

Dites, ça vous dirait pas de vous calmer un peu. Parce que dire
n'importe quoi en agressant les autres et en prenant tout le monde pour
des imbéciles, ce n'est pas bien passionnant. Chercher absolument la
manière d'interprèter ce que dit l'autre de manière à que ce puisse être
faux au lieu de chercher à comprendre ce qu'il dit, c'est aussi très
pénible.

je suis très calme, je n'ai même aucune difficulté à rester calme face à
l'insignifiance.

que "les autres" (pourquoi ce pluriel?) arrêtent précisemment
*d'initier* les trolls imbéciles et je n'aurais pas le loisir de noter
leurs contradictions.

En l'occurrence, l'intérêt d'éviter la duplication de code, c'est
essentiellement pour la maintenance. Un code dupliqué (au niveau des
sources) pose des problèmes de maintenance si une erreur est corrigé
dans une des parties dupliquées et pas dans une autre.

ah bon !
btw, là vous me prenez pas pour un imbécile, c'est ça ?

Les templates permettent d'éviter la duplication de code... source.
J'imagine que c'est ce dont parlait James.

le thread parlait de "nombre variables d'argument", il me m'intéresse
pas de savoir ce dont James parle à propos de ces templates hors sujet
mais qui "chez lui" ...

En revanche, je ne saisis pas le problème d'avoir du code binaire
dupliqué ? C'est par soucis de la taille de l'exécutable ?

j'ai dit "problème", "souci" ?? une fois de plus vous voulez par une
pirouette ("quel seraient les pbs inhérents à la taille d'un code")
masquer le fait que vos (pardon pour l'amalgame mais il ne me semble pas
déplacé) arguments étaient sans substances (n'apporte rien à la
question) et inexacts (ben oui, un template ça duplique).

Sylvain.

Sylvain wrote:

je suis très calme, je n'ai même aucune difficulté à rester calme face à
l'insignifiance.

Je suppose que là, vous n'êtes pas méprisant....

En l'occurrence, l'intérêt d'éviter la duplication de code, c'est
essentiellement pour la maintenance. Un code dupliqué (au niveau des
sources) pose des problèmes de maintenance si une erreur est corrigé
dans une des parties dupliquées et pas dans une autre.

ah bon !
btw, là vous me prenez pas pour un imbécile, c'est ça ?

Non. Mais vous n'avez visiblement pas compris ce que voulait dire James,
étant donné votre réponse.
Comme vous trouvez drôle de dire qu'un template ne duplique pas le code,
j'essaye de vous expliquer en quoi il ne le duplique pas.

Les templates permettent d'éviter la duplication de code... source.
J'imagine que c'est ce dont parlait James.

le thread parlait de "nombre variables d'argument", il me m'intéresse
pas de savoir ce dont James parle à propos de ces templates hors sujet
mais qui "chez lui" ...

Ce n'était pas hors sujet. Ou du moins, si ça l'était, c'est vous qui
l'avez introduit en disant : « vouloir mettre l'usage de l'un dans
l'autre est source de duplication de code et ne parait pas vraiment
utile ni efficace. »

En quoi la duplication de code (généré, dans votre propos) n'est-elle
pas efficace ?

En revanche, je ne saisis pas le problème d'avoir du code binaire
dupliqué ? C'est par soucis de la taille de l'exécutable ?

j'ai dit "problème", "souci" ??

Vous avez dit « ni utile ni efficace » dans un premier temps.
Ensuite, vous avez trouvé très drôle l'idée des template, ce qui, à
défaut d'autre argument, laisse sous-entendre que cela ne vous semblait
pas une solution satisfaisante.
En quoi cette solution ne vous semble-t-elle pas satisfaisante ?

une fois de plus vous voulez par une
pirouette ("quel seraient les pbs inhérents à la taille d'un code")
masquer le fait que vos (pardon pour l'amalgame mais il ne me semble pas
déplacé) arguments étaient sans substances (n'apporte rien à la
question) et inexacts (ben oui, un template ça duplique).

Un template ne duplique pas le code source, ce qui, pour la maintenance
d'une application est essentiel. Donc « un template, ça duplique »,
soit, mais ça dépend de quoi l'on parle.

Par ailleurs, je comprends très bien le problème que pose la duplication
de code source, mais j'ai du mal à saisir le problème de la duplication
du code généré. Mais vos propos laissent entendre que la duplication de
code généré induit par les templates n'est pas une solution
satisfaisante. On peut donc en déduire que, pour vous, cette duplication
pose un problème. Lequel ?

Enfin, si vous aviez compris ce que disait James lorsqu'il écrivait :
« En revanche, je ne vois pas ton point en ce qui concerne la
duplication du code -- les templates sont là pour ça. »

Pourquoi n'avoir pas répondu quelque chose du genre : « Certes, le code
source n'est pas dupliqué, mais il reste de la duplication dans le code
généré » ? C'est certainement plus utile et plus efficace (critères dont
vous avez le soucis) que « excellente celle-là !! merci ! je la note en
tête des histoires droles. ».

--
Arnaud

Sylvain wrote:
[...]
Dites, ça vous dirait pas de vous calmer un peu.

Arnaud,

je t'invite à lire <http://fr.wikipedia.org/wiki/Troll_(Internet)>.

Fabien LE LEZ wrote:

Sylvain wrote:
[...]
Dites, ça vous dirait pas de vous calmer un peu.

Arnaud,

je t'invite à lire <http://fr.wikipedia.org/wiki/Troll_(Internet)>.

Tu penses que Sylvain est un troll ? Je n'irais pas jusqu'à là.
Il manque peut-être du discernement, il ne se montre pas
particulièrement mature, ni particulièrement compétent en C++,
mais je n'ai pas l'impression qu'il intervient avec le but de
semer la pagaille. (J'avoue que quand il avait laché quelque
chose d'aussi gros que d'utiliser << 1 à la place de * 2,
j'avais mes doutes. Mais pris dans l'ensemble, je suis convaincu
que ce n'est qu'un problème de maturité et de compétence.)

--
James Kanze GABI Software
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

Sylvain wrote:

kanze wrote on 11/04/2006 11:44:

[...]

non pas que je réserve l'instruction:
errorHdlr << "monTrucVachementPropreQuiSertAFlusher";
pour réaliser le traitement (vs la mise en tampon), mais
juste que c'est trop grotesque pour que je l'imagine.

Mais je n'ai pas de truc (explicit, en tout cas) pour
déclencher le flush. J'exploite la durée de vie des
temporaires, pour que le tout soit transparent à
l'utilisateur.

ah les temporaires, un bon flush masqué dans un destructeur,
j'ai bon Monsieur devinette ?

Il n'y a pas de devinette. C'est devenu une technique quasiment
standard pour la gestion des fichiers de log.

mais alors, ton post précédent était:

Pas chez moi. Au moins, pas avec la forme avec des <<.

peux-tu nous expliquer pourquoi ton destructeur serait géné
par une méthode (T& arg(X x)) et ne le serait pas par un
opérateur << ??

C'est l'idiome du wrapper d'un flux. Je l'ai déjà présenté
maintes fois. (En fait, ce n'est qu'une incarnation particulière
du modèle de Proxy. Je l'ai trouvé ici dans certain code écrit
il y a plus de dix ans -- avec des {...} en plus, parce que les
compilateurs d'alors ne respectaient pas la durée de vie telle
qu'elle est définie par la norme aujourd'hui.)

dans le même temps, peux-tu nous expliquer comment loguer
*une* fois la même erreur survenue dans X (64, 128, ...)
threads lancés simultanément mais échouant tous pour la même
raison (extérieure aux threads).

C'est simple -- le temporaire detient un lock. Pour toute sa
durée de vie.

Là aussi, ce n'est pas la première fois que le problème s'est
posé. La solution est connue.

peux-tu également indiquer où placer ton temporaire dans une
chaine d'appels de méthodes (le C++ est procédurale, non?)
d'où on sort par des catch / throw en cascade ?

Il n'y a pas le moindre catch ni throw. C'est le temporaire qui
fait tout le boulot.

Je n'ai pas de duplication du code, parce que je me suis
servi des templates. C'est une technique connue et approuvée
par ceux qui connaissent le C++.

non, ceux qui connaissent le C++ savent que "déclarer" et
"instancier" une classe template "duplique" le code template
en code concrêt; le binaire ne contient (évidemment) pas la
classe de définition mais autant de code (dupliqué au type
classe paramètre) que de classes générées.

Et alors ? Je n'ai toujours qu'une seule copie à maintenir dans
les sources.

--
James Kanze GABI Software
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

On 12 Apr 2006 00:59:38 -0700, "kanze" <kanze@gabi-soft.fr>:

mais je n'ai pas l'impression qu'il intervient avec le but de
semer la pagaille.

Je ne connais pas son but. Je me contente de regarder le résultat.

In news:1144829411.014692.260670@t31g2000cwb.googlegroups.com,
kanze <kanze@gabi-soft.fr> typed:

C'est l'idiome du wrapper d'un flux. Je l'ai déjà présenté
maintes fois. (En fait, ce n'est qu'une incarnation particulière
du modèle de Proxy. Je l'ai trouvé ici dans certain code écrit
il y a plus de dix ans -- avec des {...} en plus, parce que les
compilateurs d'alors ne respectaient pas la durée de vie telle
qu'elle est définie par la norme aujourd'hui.)

A propos de duree de vie, je sais que le code suivant est correct:

void print(string const& s);
print(string("foo").append("bar"));

mais que se passe-t il pour celui ci:

void print(char const*s);
print(string("foo").append("bar").c_str());

Les deux compilateurs que j'ai sous la main (gcc4 et xlC6) appellent le
destructeur du temporaire quand il faut (cad apres l'appel a print), mais
je voudrait savoir si c'est un comportement garanti ou bien juste un
hasard d'implementation...

Merci pour vos lumieres.