le compilo n'a rien à voir, c'est la libc qui fait ça.
Exact, au temps pour moi
Et je suis curieux de savoir quel melange compilo/libc ne gère pas encore %2$d
idem
Antoine Leca
En news:478cf86c$0$31997$, Aris va escriure:
printf("%2$d n%1$dn", 5, 3); %2$d
%1$d mauvais compilo, changer compilo ;-)
le compilo n'a rien à voir, c'est la libc qui fait ça.
Exact.
Et je suis curieux de savoir quel melange compilo/libc ne gère pas encore %2$d
Tu serais surpris du nombre. Pour moi, il est plus facile de lister les libc qui acceptent (« gèrent correctement »)
n$ est une invention du comité X/Open (XPG) qui n'a pas vraiment fait mouche en dehors du monde Unix. Cela (et le reste des trucs liés aux idées i18n des années 90) a été avalé dans Posix-2001 au titre de la volonté commune de sortir une seule norme ou au moins une double norme avec le moins de divergences possibles. Mais dans d'autres mondes où le C n'est pas le centre du monde, la vision XPG de l'internationalisation n'est pas partagée unaniment (litote) et beaucoup sont passés olympiquement au travers. Par ailleurs, un certain nombre de fournisseurs n'ont tout simplement pas remarqués...
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).
Par ailleurs, le développement du C s'est quand même beaucoup ralenti depuis une dizaine d'années, et la norme Posix-2001 n'a encore que 7 ans... (quant à XPG4, en dehors du monde *nix, qui en fit cas ?) Au total, il est courant de trouver des bibliothèques standard qui n'ont pas toutes les dernières fioritures des normes.
Antoine
En news:478cf86c$0$31997$fa620c48@newsreader-1.edpnet.be, Aris va escriure:
printf("%2$d n%1$dn", 5, 3);
%2$d
%1$d
mauvais compilo, changer compilo ;-)
le compilo n'a rien à voir, c'est la libc qui fait ça.
Exact.
Et je suis curieux de savoir quel melange compilo/libc ne gère
pas encore %2$d
Tu serais surpris du nombre. Pour moi, il est plus facile de lister les libc
qui acceptent (« gèrent correctement »)
n$ est une invention du comité X/Open (XPG) qui n'a pas vraiment fait mouche
en dehors du monde Unix. Cela (et le reste des trucs liés aux idées i18n des
années 90) a été avalé dans Posix-2001 au titre de la volonté commune de
sortir une seule norme ou au moins une double norme avec le moins de
divergences possibles. Mais dans d'autres mondes où le C n'est pas le centre
du monde, la vision XPG de l'internationalisation n'est pas partagée
unaniment (litote) et beaucoup sont passés olympiquement au travers. Par
ailleurs, un certain nombre de fournisseurs n'ont tout simplement pas
remarqués...
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).
Par ailleurs, le développement du C s'est quand même beaucoup ralenti depuis
une dizaine d'années, et la norme Posix-2001 n'a encore que 7 ans... (quant
à XPG4, en dehors du monde *nix, qui en fit cas ?) Au total, il est courant
de trouver des bibliothèques standard qui n'ont pas toutes les dernières
fioritures des normes.
le compilo n'a rien à voir, c'est la libc qui fait ça.
Exact.
Et je suis curieux de savoir quel melange compilo/libc ne gère pas encore %2$d
Tu serais surpris du nombre. Pour moi, il est plus facile de lister les libc qui acceptent (« gèrent correctement »)
n$ est une invention du comité X/Open (XPG) qui n'a pas vraiment fait mouche en dehors du monde Unix. Cela (et le reste des trucs liés aux idées i18n des années 90) a été avalé dans Posix-2001 au titre de la volonté commune de sortir une seule norme ou au moins une double norme avec le moins de divergences possibles. Mais dans d'autres mondes où le C n'est pas le centre du monde, la vision XPG de l'internationalisation n'est pas partagée unaniment (litote) et beaucoup sont passés olympiquement au travers. Par ailleurs, un certain nombre de fournisseurs n'ont tout simplement pas remarqués...
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).
Par ailleurs, le développement du C s'est quand même beaucoup ralenti depuis une dizaine d'années, et la norme Posix-2001 n'a encore que 7 ans... (quant à XPG4, en dehors du monde *nix, qui en fit cas ?) Au total, il est courant de trouver des bibliothèques standard qui n'ont pas toutes les dernières fioritures des normes.