James Kanze wrote on 24/11/2006 21:44:évidemment c'est un feature de dubug, donc tu sais que les chaines
formattées ne dépassent jamais la longueur réservée (2048 ici) ...
Jusqu'elles le font.
pardon ?
Pourquoi 2048, d'ailleurs ? Pourquoi pas
2000 ? Ou 10000 ?
parce que j'ai dit "je choisis arbitrairement 2048!!!"
De l'autre côté, il y a toujours le problème des types qui ne
conviennent pas.
s'il n'y avait qu'un vague problème de type lorque l'on a besoin de
faire de sortie vers la "console systeme" tout irait bien!!!
la question n'est pas ici, est-ce que je suis capable d'écrire
toto("%d %s", 32, "heelo world")
ou au contraire suffisemment con pour mettre
toto("%d %s %i %c %f", "hello world", 25, "bouf", "pan")
mais juste de tracer (par exemple) si l'on rentre ou non dans une
fonction qui ne peut pas être tracée sous debugger symbolique.Printf et compagnie, c'est un core dump larvé.
lorsque l'on fait exprès d'être bête, oui.
Comme Loïc, je ne trouve pas la syntaxe de printf
particulièrement conviviable. Mais si on y tient, il y a
boost::format.
bien sur il y a toujours des centaines de kilos de librairie pour
remplacer une primitive inutilement (dans le contexte) du CRT, ...
Il y a même une classe équivalente à mon site,
dans le répertoire Old/Text. (Je ne la maintient plus,
parce que je n'en vois pas l'utilité.)
?! moi non plus je ne verrais pas l'utilité d'une usine à gaz pour
logger des "in toto, leaving titi".
James Kanze wrote on 24/11/2006 21:44:
évidemment c'est un feature de dubug, donc tu sais que les chaines
formattées ne dépassent jamais la longueur réservée (2048 ici) ...
Jusqu'elles le font.
pardon ?
Pourquoi 2048, d'ailleurs ? Pourquoi pas
2000 ? Ou 10000 ?
parce que j'ai dit "je choisis arbitrairement 2048!!!"
De l'autre côté, il y a toujours le problème des types qui ne
conviennent pas.
s'il n'y avait qu'un vague problème de type lorque l'on a besoin de
faire de sortie vers la "console systeme" tout irait bien!!!
la question n'est pas ici, est-ce que je suis capable d'écrire
toto("%d %s", 32, "heelo world")
ou au contraire suffisemment con pour mettre
toto("%d %s %i %c %f", "hello world", 25, "bouf", "pan")
mais juste de tracer (par exemple) si l'on rentre ou non dans une
fonction qui ne peut pas être tracée sous debugger symbolique.
Printf et compagnie, c'est un core dump larvé.
lorsque l'on fait exprès d'être bête, oui.
Comme Loïc, je ne trouve pas la syntaxe de printf
particulièrement conviviable. Mais si on y tient, il y a
boost::format.
bien sur il y a toujours des centaines de kilos de librairie pour
remplacer une primitive inutilement (dans le contexte) du CRT, ...
Il y a même une classe équivalente à mon site,
dans le répertoire Old/Text. (Je ne la maintient plus,
parce que je n'en vois pas l'utilité.)
?! moi non plus je ne verrais pas l'utilité d'une usine à gaz pour
logger des "in toto, leaving titi".
James Kanze wrote on 24/11/2006 21:44:évidemment c'est un feature de dubug, donc tu sais que les chaines
formattées ne dépassent jamais la longueur réservée (2048 ici) ...
Jusqu'elles le font.
pardon ?
Pourquoi 2048, d'ailleurs ? Pourquoi pas
2000 ? Ou 10000 ?
parce que j'ai dit "je choisis arbitrairement 2048!!!"
De l'autre côté, il y a toujours le problème des types qui ne
conviennent pas.
s'il n'y avait qu'un vague problème de type lorque l'on a besoin de
faire de sortie vers la "console systeme" tout irait bien!!!
la question n'est pas ici, est-ce que je suis capable d'écrire
toto("%d %s", 32, "heelo world")
ou au contraire suffisemment con pour mettre
toto("%d %s %i %c %f", "hello world", 25, "bouf", "pan")
mais juste de tracer (par exemple) si l'on rentre ou non dans une
fonction qui ne peut pas être tracée sous debugger symbolique.Printf et compagnie, c'est un core dump larvé.
lorsque l'on fait exprès d'être bête, oui.
Comme Loïc, je ne trouve pas la syntaxe de printf
particulièrement conviviable. Mais si on y tient, il y a
boost::format.
bien sur il y a toujours des centaines de kilos de librairie pour
remplacer une primitive inutilement (dans le contexte) du CRT, ...
Il y a même une classe équivalente à mon site,
dans le répertoire Old/Text. (Je ne la maintient plus,
parce que je n'en vois pas l'utilité.)
?! moi non plus je ne verrais pas l'utilité d'une usine à gaz pour
logger des "in toto, leaving titi".
Loïc Joly wrote on 24/11/2006 23:14:J'ai déjà vu des bugs dans du code de log écrit à la printf.
je l'ai dit, on a le droit d'être nul, stupide, incompétent, ...
Loïc Joly wrote on 24/11/2006 23:14:
J'ai déjà vu des bugs dans du code de log écrit à la printf.
je l'ai dit, on a le droit d'être nul, stupide, incompétent, ...
Loïc Joly wrote on 24/11/2006 23:14:J'ai déjà vu des bugs dans du code de log écrit à la printf.
je l'ai dit, on a le droit d'être nul, stupide, incompétent, ...
Loïc Joly wrote on 25/11/2006 09:38:[] on peut partir, sur un retour std::string,
qui donne le résultat attendu.
Et n'est pas utilisable directement dans un printf...
?! parce qu'il n'a pas d'opérateurs de coercion vers const char* ?
une raison de plus (pour moi) de ne pas l'utiliser.
Loïc Joly wrote on 25/11/2006 09:38:
[] on peut partir, sur un retour std::string,
qui donne le résultat attendu.
Et n'est pas utilisable directement dans un printf...
?! parce qu'il n'a pas d'opérateurs de coercion vers const char* ?
une raison de plus (pour moi) de ne pas l'utiliser.
Loïc Joly wrote on 25/11/2006 09:38:[] on peut partir, sur un retour std::string,
qui donne le résultat attendu.
Et n'est pas utilisable directement dans un printf...
?! parce qu'il n'a pas d'opérateurs de coercion vers const char* ?
une raison de plus (pour moi) de ne pas l'utiliser.
Sylvain wrote:Loïc Joly wrote on 24/11/2006 23:14:J'ai déjà vu des bugs dans du code de log écrit à la printf.
je l'ai dit, on a le droit d'être nul, stupide, incompétent, ...
Est-ce qu'on a aussi le droit d'être arrogant, prétentieux, et
faire semblant de ne jamais faire des erreurs ?
Sylvain wrote:
Loïc Joly wrote on 24/11/2006 23:14:
J'ai déjà vu des bugs dans du code de log écrit à la printf.
je l'ai dit, on a le droit d'être nul, stupide, incompétent, ...
Est-ce qu'on a aussi le droit d'être arrogant, prétentieux, et
faire semblant de ne jamais faire des erreurs ?
Sylvain wrote:Loïc Joly wrote on 24/11/2006 23:14:J'ai déjà vu des bugs dans du code de log écrit à la printf.
je l'ai dit, on a le droit d'être nul, stupide, incompétent, ...
Est-ce qu'on a aussi le droit d'être arrogant, prétentieux, et
faire semblant de ne jamais faire des erreurs ?
Non, il n'y a pas d'opérateur de conversion implicite vers const
char*. Les auteurs de std::string n'étaient pas complétement
incompétant. (Les auteurs de C99 non plus, qui l'ont estîmé
nécessaire de créer un remplaçant de sprintf, parce qu'il n'y a
pas d'utilisation correcte possible de sprintf.)
Comme Sylvain l'a dit, « on a le droit d'être nul, stupide,
incompétent,... » Il ne fait qu'exercer ses droits.
toto("%d %s %i %c %f", "hello world", 25, "bouf", "pan")
une raison de plus (pour moi) de ne pas l'utiliser.
Mieux vaut du code incorrect, n'est-ce pas ?
Non, il n'y a pas d'opérateur de conversion implicite vers const
char*. Les auteurs de std::string n'étaient pas complétement
incompétant. (Les auteurs de C99 non plus, qui l'ont estîmé
nécessaire de créer un remplaçant de sprintf, parce qu'il n'y a
pas d'utilisation correcte possible de sprintf.)
Comme Sylvain l'a dit, « on a le droit d'être nul, stupide,
incompétent,... » Il ne fait qu'exercer ses droits.
toto("%d %s %i %c %f", "hello world", 25, "bouf", "pan")
une raison de plus (pour moi) de ne pas l'utiliser.
Mieux vaut du code incorrect, n'est-ce pas ?
Non, il n'y a pas d'opérateur de conversion implicite vers const
char*. Les auteurs de std::string n'étaient pas complétement
incompétant. (Les auteurs de C99 non plus, qui l'ont estîmé
nécessaire de créer un remplaçant de sprintf, parce qu'il n'y a
pas d'utilisation correcte possible de sprintf.)
Comme Sylvain l'a dit, « on a le droit d'être nul, stupide,
incompétent,... » Il ne fait qu'exercer ses droits.
toto("%d %s %i %c %f", "hello world", 25, "bouf", "pan")
une raison de plus (pour moi) de ne pas l'utiliser.
Mieux vaut du code incorrect, n'est-ce pas ?
James Kanze wrote on 26/11/2006 13:27:Non, il n'y a pas d'opérateur de conversion implicite vers const
char*. Les auteurs de std::string n'étaient pas complétement
incompétant. (Les auteurs de C99 non plus, qui l'ont estîmé
nécessaire de créer un remplaçant de sprintf, parce qu'il n'y a
pas d'utilisation correcte possible de sprintf.)
qui a parlé de la compétence des auteurs de string ou de C99 ???
oser utiliser quelque chose de différent de la production de ces auteurs
serait *par essence* irrespectueux, les dénigrer ???
gageons que ces auteurs là n'ont pas la susceptibilité aussi mal plac ée
que tu le prétends.Comme Sylvain l'a dit, « on a le droit d'être nul, stupide,
incompétent,... » Il ne fait qu'exercer ses droits.
pouf, pouf, pouf !!!
"être nul" dans ma citation, c'est écrire:toto("%d %s %i %c %f", "hello world", 25, "bouf", "pan")
essaie de citer correctement, cela évitera les insultes gratuites.
une raison de plus (pour moi) de ne pas l'utiliser.
Mieux vaut du code incorrect, n'est-ce pas ?
donc *par essence* tout ce qui est production personnelle est incorrect,
hmm, tu considères cela pour ton code aussi alors ...
James Kanze wrote on 26/11/2006 13:27:
Non, il n'y a pas d'opérateur de conversion implicite vers const
char*. Les auteurs de std::string n'étaient pas complétement
incompétant. (Les auteurs de C99 non plus, qui l'ont estîmé
nécessaire de créer un remplaçant de sprintf, parce qu'il n'y a
pas d'utilisation correcte possible de sprintf.)
qui a parlé de la compétence des auteurs de string ou de C99 ???
oser utiliser quelque chose de différent de la production de ces auteurs
serait *par essence* irrespectueux, les dénigrer ???
gageons que ces auteurs là n'ont pas la susceptibilité aussi mal plac ée
que tu le prétends.
Comme Sylvain l'a dit, « on a le droit d'être nul, stupide,
incompétent,... » Il ne fait qu'exercer ses droits.
pouf, pouf, pouf !!!
"être nul" dans ma citation, c'est écrire:
toto("%d %s %i %c %f", "hello world", 25, "bouf", "pan")
essaie de citer correctement, cela évitera les insultes gratuites.
une raison de plus (pour moi) de ne pas l'utiliser.
Mieux vaut du code incorrect, n'est-ce pas ?
donc *par essence* tout ce qui est production personnelle est incorrect,
hmm, tu considères cela pour ton code aussi alors ...
James Kanze wrote on 26/11/2006 13:27:Non, il n'y a pas d'opérateur de conversion implicite vers const
char*. Les auteurs de std::string n'étaient pas complétement
incompétant. (Les auteurs de C99 non plus, qui l'ont estîmé
nécessaire de créer un remplaçant de sprintf, parce qu'il n'y a
pas d'utilisation correcte possible de sprintf.)
qui a parlé de la compétence des auteurs de string ou de C99 ???
oser utiliser quelque chose de différent de la production de ces auteurs
serait *par essence* irrespectueux, les dénigrer ???
gageons que ces auteurs là n'ont pas la susceptibilité aussi mal plac ée
que tu le prétends.Comme Sylvain l'a dit, « on a le droit d'être nul, stupide,
incompétent,... » Il ne fait qu'exercer ses droits.
pouf, pouf, pouf !!!
"être nul" dans ma citation, c'est écrire:toto("%d %s %i %c %f", "hello world", 25, "bouf", "pan")
essaie de citer correctement, cela évitera les insultes gratuites.
une raison de plus (pour moi) de ne pas l'utiliser.
Mieux vaut du code incorrect, n'est-ce pas ?
donc *par essence* tout ce qui est production personnelle est incorrect,
hmm, tu considères cela pour ton code aussi alors ...
Jean-Marc Bourguet wrote on 25/11/2006 20:42:Passer une instance de classe à une fonction variadique,
c'est un comportement indéfini, [...]
passer des instances à printf() surement - *personne ne l'a évoqué ici*
Loïc Joly wrote on 25/11/2006 09:38:[] on peut partir, sur un retour std::string, qui donne le résultat
attendu.
Et n'est pas utilisable directement dans un printf...
?! parce qu'il n'a pas d'opérateurs de coercion vers const char* ?
une raison de plus (pour moi) de ne pas l'utiliser.
Sylvain.
ailleurs, ie à une fonction variadique prévu pour, cela sera défini, par
ce que fait la fonction justement.
Jean-Marc Bourguet wrote on 25/11/2006 20:42:
Passer une instance de classe à une fonction variadique,
c'est un comportement indéfini, [...]
passer des instances à printf() surement - *personne ne l'a évoqué ici*
Loïc Joly wrote on 25/11/2006 09:38:
[] on peut partir, sur un retour std::string, qui donne le résultat
attendu.
Et n'est pas utilisable directement dans un printf...
?! parce qu'il n'a pas d'opérateurs de coercion vers const char* ?
une raison de plus (pour moi) de ne pas l'utiliser.
Sylvain.
ailleurs, ie à une fonction variadique prévu pour, cela sera défini, par
ce que fait la fonction justement.
Jean-Marc Bourguet wrote on 25/11/2006 20:42:Passer une instance de classe à une fonction variadique,
c'est un comportement indéfini, [...]
passer des instances à printf() surement - *personne ne l'a évoqué ici*
Loïc Joly wrote on 25/11/2006 09:38:[] on peut partir, sur un retour std::string, qui donne le résultat
attendu.
Et n'est pas utilisable directement dans un printf...
?! parce qu'il n'a pas d'opérateurs de coercion vers const char* ?
une raison de plus (pour moi) de ne pas l'utiliser.
Sylvain.
ailleurs, ie à une fonction variadique prévu pour, cela sera défini, par
ce que fait la fonction justement.
Sylvain wrote:James Kanze wrote on 24/11/2006 21:44:évidemment c'est un feature de dubug, donc tu sais que les chaines
formattées ne dépassent jamais la longueur réservée (2048 ici)....
Jusqu'elles le font.
pardon ?
C'est que tu sais que les chaînes formattées ne dépasseront
jamais la longueur réservée, jusqu'elles le font.
C-à-d qu'en fait, tu n'en sais rien, au moins de pouvoir voir
dans la future.
Pourquoi 2048, d'ailleurs ? Pourquoi pas
2000 ? Ou 10000 ?
parce que j'ai dit "je choisis arbitrairement 2048!!!"
D'accord, mais alors, pourquoi pas 2 ? Si le choix est
réelement arbitraire, 2, c'est aussi bien 2048.
De l'autre côté, il y a toujours le problème des types qui ne
conviennent pas.
s'il n'y avait qu'un vague problème de type lorque l'on a besoin de
faire de sortie vers la "console systeme" tout irait bien!!!
Peut-être, mais pourquoi ajouter aux problèmes ?
Lorsqu'on n'est pas parfait, oui. Toi, peut-être, tu es parfait
et ne fais jamais d'erreurs, mais ce n'est le cas d'aucun
programmeur que je n'ai jamais rencontré.
Une primative qui garantit un core dump à la longue, oui.
Une primative dont l'utilisation est interdite dans toutes les
règles de codage que je connais.
Si c'est tous ce qu'on veut, évidemment, std::cout fait très
bien l'affaire.
Sylvain wrote:
James Kanze wrote on 24/11/2006 21:44:
évidemment c'est un feature de dubug, donc tu sais que les chaines
formattées ne dépassent jamais la longueur réservée (2048 ici)....
Jusqu'elles le font.
pardon ?
C'est que tu sais que les chaînes formattées ne dépasseront
jamais la longueur réservée, jusqu'elles le font.
C-à-d qu'en fait, tu n'en sais rien, au moins de pouvoir voir
dans la future.
Pourquoi 2048, d'ailleurs ? Pourquoi pas
2000 ? Ou 10000 ?
parce que j'ai dit "je choisis arbitrairement 2048!!!"
D'accord, mais alors, pourquoi pas 2 ? Si le choix est
réelement arbitraire, 2, c'est aussi bien 2048.
De l'autre côté, il y a toujours le problème des types qui ne
conviennent pas.
s'il n'y avait qu'un vague problème de type lorque l'on a besoin de
faire de sortie vers la "console systeme" tout irait bien!!!
Peut-être, mais pourquoi ajouter aux problèmes ?
Lorsqu'on n'est pas parfait, oui. Toi, peut-être, tu es parfait
et ne fais jamais d'erreurs, mais ce n'est le cas d'aucun
programmeur que je n'ai jamais rencontré.
Une primative qui garantit un core dump à la longue, oui.
Une primative dont l'utilisation est interdite dans toutes les
règles de codage que je connais.
Si c'est tous ce qu'on veut, évidemment, std::cout fait très
bien l'affaire.
Sylvain wrote:James Kanze wrote on 24/11/2006 21:44:évidemment c'est un feature de dubug, donc tu sais que les chaines
formattées ne dépassent jamais la longueur réservée (2048 ici)....
Jusqu'elles le font.
pardon ?
C'est que tu sais que les chaînes formattées ne dépasseront
jamais la longueur réservée, jusqu'elles le font.
C-à-d qu'en fait, tu n'en sais rien, au moins de pouvoir voir
dans la future.
Pourquoi 2048, d'ailleurs ? Pourquoi pas
2000 ? Ou 10000 ?
parce que j'ai dit "je choisis arbitrairement 2048!!!"
D'accord, mais alors, pourquoi pas 2 ? Si le choix est
réelement arbitraire, 2, c'est aussi bien 2048.
De l'autre côté, il y a toujours le problème des types qui ne
conviennent pas.
s'il n'y avait qu'un vague problème de type lorque l'on a besoin de
faire de sortie vers la "console systeme" tout irait bien!!!
Peut-être, mais pourquoi ajouter aux problèmes ?
Lorsqu'on n'est pas parfait, oui. Toi, peut-être, tu es parfait
et ne fais jamais d'erreurs, mais ce n'est le cas d'aucun
programmeur que je n'ai jamais rencontré.
Une primative qui garantit un core dump à la longue, oui.
Une primative dont l'utilisation est interdite dans toutes les
règles de codage que je connais.
Si c'est tous ce qu'on veut, évidemment, std::cout fait très
bien l'affaire.
qui a parlé de la compétence des auteurs de string ou de C99 ???
Tu as critiqué l'absense d'une conversion implicite dans
std::string.
?! parce qu'il n'a pas d'opérateurs de coercion vers const char* ?
Quant aux auteurs de C99, ils ont considéré que sprintf, dans sa
forme actuelle, n'était pas utilisable.
[...]
Et quelle est la différence entre ça et :
sprintf( buf, "%s", x.toString() ) ;
ou x.toString() renvoie un std::string ? Je n'en vois pas.
Je trouve qu'utiliser sprintf n'est pas correct non plus. (En
fait, c'est possible à l'utiliser, mais c'est extrèmement
complexe, et il exige un buffer alloué dynamiquement, dont on a
calculé la taille en fonction du contenu de la chaîne de
formattage.)
qui a parlé de la compétence des auteurs de string ou de C99 ???
Tu as critiqué l'absense d'une conversion implicite dans
std::string.
?! parce qu'il n'a pas d'opérateurs de coercion vers const char* ?
Quant aux auteurs de C99, ils ont considéré que sprintf, dans sa
forme actuelle, n'était pas utilisable.
[...]
Et quelle est la différence entre ça et :
sprintf( buf, "%s", x.toString() ) ;
ou x.toString() renvoie un std::string ? Je n'en vois pas.
Je trouve qu'utiliser sprintf n'est pas correct non plus. (En
fait, c'est possible à l'utiliser, mais c'est extrèmement
complexe, et il exige un buffer alloué dynamiquement, dont on a
calculé la taille en fonction du contenu de la chaîne de
formattage.)
qui a parlé de la compétence des auteurs de string ou de C99 ???
Tu as critiqué l'absense d'une conversion implicite dans
std::string.
?! parce qu'il n'a pas d'opérateurs de coercion vers const char* ?
Quant aux auteurs de C99, ils ont considéré que sprintf, dans sa
forme actuelle, n'était pas utilisable.
[...]
Et quelle est la différence entre ça et :
sprintf( buf, "%s", x.toString() ) ;
ou x.toString() renvoie un std::string ? Je n'en vois pas.
Je trouve qu'utiliser sprintf n'est pas correct non plus. (En
fait, c'est possible à l'utiliser, mais c'est extrèmement
complexe, et il exige un buffer alloué dynamiquement, dont on a
calculé la taille en fonction du contenu de la chaîne de
formattage.)
en clair ? parce qu'un driver, un module proche du système, plein de
code, n'ont pas à s'encombrer des librairies qui ne leur servent à rien;
par contre ils savent avec certitude que pour formatter une chaine de 5
caractères(8bit) + un espace + un int32, 18 caractères suffiront même
dans le futur -- ah c'est vrai on n'apprend plus à compter (même
l'addition) à l'école, et ce serait débile d'apprendre ça puisqu'il y a
std::trucQuiLuiSaitCompter.
en clair ? parce qu'un driver, un module proche du système, plein de
code, n'ont pas à s'encombrer des librairies qui ne leur servent à rien;
par contre ils savent avec certitude que pour formatter une chaine de 5
caractères(8bit) + un espace + un int32, 18 caractères suffiront même
dans le futur -- ah c'est vrai on n'apprend plus à compter (même
l'addition) à l'école, et ce serait débile d'apprendre ça puisqu'il y a
std::trucQuiLuiSaitCompter.
en clair ? parce qu'un driver, un module proche du système, plein de
code, n'ont pas à s'encombrer des librairies qui ne leur servent à rien;
par contre ils savent avec certitude que pour formatter une chaine de 5
caractères(8bit) + un espace + un int32, 18 caractères suffiront même
dans le futur -- ah c'est vrai on n'apprend plus à compter (même
l'addition) à l'école, et ce serait débile d'apprendre ça puisqu'il y a
std::trucQuiLuiSaitCompter.
