C'est surtout que UTF8 et ses copains sont aussi des normes ISO, donc on peut y faire référence dans une norme ISO. Tandis que cp1252 n'est pas une norme ISO.
Ah l'ISO... De ce que je connais, il n'y a que deux approches de la normalisation ISO:
la "branlette intellectuelle": des mecs pointus te pondent un standard en réfléchissant aux besoins de dans 10 ans. Ils font un truc, très complet, très théorique et très difficile à mettre en oeuvre. Au final, quand le besoin de dans 10 ans arrive, tout le monde a utilisé une méthode 10 fois plus simple et moins compatible pour faire la même chose.
la normalisation a posteriori: le truc qui a été inventé il y a 20 ans, qui est un standard de fait depuis 10 ans finit dans l'ISO pour y vivre paisiblement ... et y mourir.
Dans quelques rares cas, l'ISO pond un truc utilisable dès aujourd'hui pour les besoins d'aujourd'hui.
Quand tu es programmeur dans le monde réel, l'ISO te semble bien loin.
c'est aussi du boulot de maintenir une telle bibliothèque
C'est quoi cet argument ? Parce que pondre un standard, c'est pas du boulot ? Le but d'une bibliothèque, c'est bien de faire gagner du temps au développeur en prenant en charge une tâche difficile. Si ta lib ne fournit que des services faciles à implémenter directement par le développeur, elle ne sert à rien, il la fera lui-même (ce qui est le cas pour beaucoup de bibliothèques gérant des strings).
En plus pour le coup, ton argument tombe à plat: ajouter l'encodage cp1252, c'est un truc que tu fais une fois dans la vie de la bibliothèque, ça ne bouge plus jamais. Les string C++ ayant déjà de quoi gérer les conversions vers l'UTF8, UTF16, UTF32, UCS2 et UCS4, c'est pas dur de rajouter d'autres encodings.
[^] # Re: Qt > Gtk
Posté par Philippe F (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 0.
Ah l'ISO... De ce que je connais, il n'y a que deux approches de la normalisation ISO:
la "branlette intellectuelle": des mecs pointus te pondent un standard en réfléchissant aux besoins de dans 10 ans. Ils font un truc, très complet, très théorique et très difficile à mettre en oeuvre. Au final, quand le besoin de dans 10 ans arrive, tout le monde a utilisé une méthode 10 fois plus simple et moins compatible pour faire la même chose.
la normalisation a posteriori: le truc qui a été inventé il y a 20 ans, qui est un standard de fait depuis 10 ans finit dans l'ISO pour y vivre paisiblement ... et y mourir.
Dans quelques rares cas, l'ISO pond un truc utilisable dès aujourd'hui pour les besoins d'aujourd'hui.
Quand tu es programmeur dans le monde réel, l'ISO te semble bien loin.
C'est quoi cet argument ? Parce que pondre un standard, c'est pas du boulot ? Le but d'une bibliothèque, c'est bien de faire gagner du temps au développeur en prenant en charge une tâche difficile. Si ta lib ne fournit que des services faciles à implémenter directement par le développeur, elle ne sert à rien, il la fera lui-même (ce qui est le cas pour beaucoup de bibliothèques gérant des strings).
En plus pour le coup, ton argument tombe à plat: ajouter l'encodage cp1252, c'est un truc que tu fais une fois dans la vie de la bibliothèque, ça ne bouge plus jamais. Les string C++ ayant déjà de quoi gérer les conversions vers l'UTF8, UTF16, UTF32, UCS2 et UCS4, c'est pas dur de rajouter d'autres encodings.
Pour voir ce que ça donne quand tu fais le travail jusqu'au bout: http://docs.python.org/3/library/codecs.html#standard-encodings