Quand tu es programmeur dans le monde réel, l'ISO te semble bien loin.
Tu sais que C, C++, Ada, Fortran, une bonne partie d'Unicode, PDF (1.5), pour ne citer que les plus connus, sont des normes ISO.
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.
Non mais je vais le dire plus clairement : cp1252 ne sera jamais dans C++, sois en bien certain. Parce que déjà, il y aurait des encodings à considérer avant (notamment les encodings utilisés en Asie), et que de toute façon, étant un encoding propriétaire et pas ISO, il ne pourra jamais faire partie d'une norme ISO, c'est aussi simple que ça. Donc, il ne sera jamais dans C++. Ce n'est pas le rôle de C++ d'être exhaustif, c'est le rôle de bibliothèques externes. Donc, rien à voir avec Python notamment, qui n'est pas normalisé et où les gens font bien ce qu'ils veulent.
[^] # Re: Qt > Gtk
Posté par rewind (Mastodon) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 4.
Tu sais que C, C++, Ada, Fortran, une bonne partie d'Unicode, PDF (1.5), pour ne citer que les plus connus, sont des normes ISO.
Non mais je vais le dire plus clairement : cp1252 ne sera jamais dans C++, sois en bien certain. Parce que déjà, il y aurait des encodings à considérer avant (notamment les encodings utilisés en Asie), et que de toute façon, étant un encoding propriétaire et pas ISO, il ne pourra jamais faire partie d'une norme ISO, c'est aussi simple que ça. Donc, il ne sera jamais dans C++. Ce n'est pas le rôle de C++ d'être exhaustif, c'est le rôle de bibliothèques externes. Donc, rien à voir avec Python notamment, qui n'est pas normalisé et où les gens font bien ce qu'ils veulent.