En ce qui concerne n$, cela représente un poids non-négligeable de code et de cycles inutiles, qui plus est dans une portion de code (printf) qui est déjà très mal vue pour son embompoint (évidement, cela concerne surtout ceux qui travaillent avec des bibliothèques liés statiquement).
Tu sur-simplifies encore un peu la situation. Pour pouvoir gerer proprement $n, il faut fabriquer la liste des arguments a part. Comme on ne sait pas vraiment quelle longueur elle a, ca demande d'allouer de la memoire... C'est le seul bout de printf (si on excepte les zigouigoui dynamiques comme les locale) qui a vraiment besoin d'allouer de la memoire.
-> ca coince, difficile de faire un printf exception-safe avec $n.
In article <fmiqnu$sma$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:
En ce qui concerne n$, cela représente un poids non-négligeable de code et
de cycles inutiles, qui plus est dans une portion de code (printf) qui est
déjà très mal vue pour son embompoint (évidement, cela concerne surtout ceux
qui travaillent avec des bibliothèques liés statiquement).
Tu sur-simplifies encore un peu la situation. Pour pouvoir gerer proprement
$n, il faut fabriquer la liste des arguments a part. Comme on ne sait pas
vraiment quelle longueur elle a, ca demande d'allouer de la memoire...
C'est le seul bout de printf (si on excepte les zigouigoui dynamiques
comme les locale) qui a vraiment besoin d'allouer de la memoire.
-> ca coince, difficile de faire un printf exception-safe avec $n.
En ce qui concerne n$, cela représente un poids non-négligeable de code et de cycles inutiles, qui plus est dans une portion de code (printf) qui est déjà très mal vue pour son embompoint (évidement, cela concerne surtout ceux qui travaillent avec des bibliothèques liés statiquement).
Tu sur-simplifies encore un peu la situation. Pour pouvoir gerer proprement $n, il faut fabriquer la liste des arguments a part. Comme on ne sait pas vraiment quelle longueur elle a, ca demande d'allouer de la memoire... C'est le seul bout de printf (si on excepte les zigouigoui dynamiques comme les locale) qui a vraiment besoin d'allouer de la memoire.
-> ca coince, difficile de faire un printf exception-safe avec $n.
Antoine Leca
En news:fmissb$gl7$, Marc Espie va escriure:
In article <fmiqnu$sma$, Antoine Leca wrote:
En ce qui concerne n$, cela représente un poids non-négligeable de code et de cycles inutiles, qui plus est dans une portion de code (printf) qui est déjà très mal vue pour son embompoint (évidement, cela concerne surtout ceux qui travaillent avec des bibliothèques liés statiquement).
Tu sur-simplifies encore un peu la situation.
:-D
[couic] Tu as parfaitement raison. Il faut croire que lorsque je m'étais penché sur ce point-là, j'avais été tellement horrifié par cette nécessité d'allouer de la mémoire dans printf() que j'avais purement et simplement effacé cette nécessité de ma mémoire (toute autre hypothèse invoquant mon grand âge ou Alzheimer est écartée d'office, évidemment.)
C'est le seul bout de printf (si on excepte les zigouigoui dynamiques comme les locale) qui a vraiment besoin d'allouer de la memoire.
En y réfléchissant un peu (pas beaucoup), il doit y avoir une possibilité de faire sans allocation dynamique, en traduisant à la volée chacun des arguments n$ et en indexant dans le va_list ; évidemment cela suppose que tous les arguments aient exactement la même taille, ce qui est une hypothèse plausible sur une babasse 64 bits, tant qu'il n'y a pas d'extensions à printf pour imprimer directement les complexes, et en supposant évidemment que long double et intmax_t sont sur 64 bits : pas un bon pari si on écrit du code portable (genre NetBSD ;) ), mais ce peut-être OK pour d'autres.
Par ailleurs, je suis allé vérifié dans SUS ce que disait la norme à ce sujet (pour vérifier mon hypothèse). Et la norme est plus restreinte que ce que je ne pensais hier, en fait %n$ ne fait partie de Posix-2001, c'est une « extension XSI » (X/Open, norme XPG6). Ce qui cohérent avec la remarque de Marc sur le surcoût imposé.
Antoine
En news:fmissb$gl7$2@biggoron.nerim.net, Marc Espie va escriure:
In article <fmiqnu$sma$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:
En ce qui concerne n$, cela représente un poids non-négligeable de
code et de cycles inutiles, qui plus est dans une portion de code
(printf) qui est déjà très mal vue pour son embompoint (évidement,
cela concerne surtout ceux qui travaillent avec des bibliothèques
liés statiquement).
Tu sur-simplifies encore un peu la situation.
:-D
[couic]
Tu as parfaitement raison. Il faut croire que lorsque je m'étais penché sur
ce point-là, j'avais été tellement horrifié par cette nécessité d'allouer de
la mémoire dans printf() que j'avais purement et simplement effacé cette
nécessité de ma mémoire (toute autre hypothèse invoquant mon grand âge ou
Alzheimer est écartée d'office, évidemment.)
C'est le seul bout de printf (si on excepte les zigouigoui dynamiques
comme les locale) qui a vraiment besoin d'allouer de la memoire.
En y réfléchissant un peu (pas beaucoup), il doit y avoir une possibilité de
faire sans allocation dynamique, en traduisant à la volée chacun des
arguments n$ et en indexant dans le va_list ; évidemment cela suppose que
tous les arguments aient exactement la même taille, ce qui est une hypothèse
plausible sur une babasse 64 bits, tant qu'il n'y a pas d'extensions à
printf pour imprimer directement les complexes, et en supposant évidemment
que long double et intmax_t sont sur 64 bits : pas un bon pari si on écrit
du code portable (genre NetBSD ;) ), mais ce peut-être OK pour d'autres.
Par ailleurs, je suis allé vérifié dans SUS ce que disait la norme à ce
sujet (pour vérifier mon hypothèse). Et la norme est plus restreinte que ce
que je ne pensais hier, en fait %n$ ne fait partie de Posix-2001, c'est une
« extension XSI » (X/Open, norme XPG6). Ce qui cohérent avec la remarque de
Marc sur le surcoût imposé.
En ce qui concerne n$, cela représente un poids non-négligeable de code et de cycles inutiles, qui plus est dans une portion de code (printf) qui est déjà très mal vue pour son embompoint (évidement, cela concerne surtout ceux qui travaillent avec des bibliothèques liés statiquement).
Tu sur-simplifies encore un peu la situation.
:-D
[couic] Tu as parfaitement raison. Il faut croire que lorsque je m'étais penché sur ce point-là, j'avais été tellement horrifié par cette nécessité d'allouer de la mémoire dans printf() que j'avais purement et simplement effacé cette nécessité de ma mémoire (toute autre hypothèse invoquant mon grand âge ou Alzheimer est écartée d'office, évidemment.)
C'est le seul bout de printf (si on excepte les zigouigoui dynamiques comme les locale) qui a vraiment besoin d'allouer de la memoire.
En y réfléchissant un peu (pas beaucoup), il doit y avoir une possibilité de faire sans allocation dynamique, en traduisant à la volée chacun des arguments n$ et en indexant dans le va_list ; évidemment cela suppose que tous les arguments aient exactement la même taille, ce qui est une hypothèse plausible sur une babasse 64 bits, tant qu'il n'y a pas d'extensions à printf pour imprimer directement les complexes, et en supposant évidemment que long double et intmax_t sont sur 64 bits : pas un bon pari si on écrit du code portable (genre NetBSD ;) ), mais ce peut-être OK pour d'autres.
Par ailleurs, je suis allé vérifié dans SUS ce que disait la norme à ce sujet (pour vérifier mon hypothèse). Et la norme est plus restreinte que ce que je ne pensais hier, en fait %n$ ne fait partie de Posix-2001, c'est une « extension XSI » (X/Open, norme XPG6). Ce qui cohérent avec la remarque de Marc sur le surcoût imposé.
