Discussion :

[Franck.H]

Je me posais une question soudainement... Peut-on utiliser le type wchar_t en lieu et place des char traditionnels sans soucis de compatibilité ? Je parle bien sûr de pouvoir lire tous type d'encodage même le plus basique comme l'ASCII !

pour vos éclaircissement

[moins1]

Peut-on utiliser le type wchar_t en lieu et place des char traditionnels sans soucis de compatibilité ?

Ce serait tellement l'fun! Malheureusement, je pense pas. Y'a des petits malins qui ont décidé de faire ça compliqué: UTF-8, UTF-16 avec ou sans BOM etc etc. Et d'autre avec ANSI.

En tout cas si quelqu'un a la recette miracle, je suis preneur.

[Zenol]

Ce n'est pas si simple. La gestion de l'encodage est généralement un bon gros bazars pour les maintainers de libs, et parfois aussi pour les utilisateurs.

Déjà, pour wchar_t, c'est mal partie :

"The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently, programs that need to be portable across any C or C++ compiler should not use wchar_t for storing Unicode text. The wchar_t type is intended for storing compiler-defined wide characters, which may be Unicode characters in some compilers."

Ref : http://en.wikipedia.org/wiki/Wide_character

Après, tu a 'char16_t and char32_t' comme indiqué sur wikipedia, mais ça ne te fera pas le café. C'est à toi de décode l'encodage de ton entrée, de convertir vers le bon format (les cas classiques sontLatin1-> Utf-16 etUtf-8->Utf16, et tu stoke tes données en mémoire comme de l'utf-16), encoder ta sortie dans le bon format, savoir comment détecter le format de ton entrée (bienvenu en enfer ), etc.
Attention aussi au fait qu'il y à UTF-16 Big Endian et UTF-16 Low Endian (http://fr.wikipedia.org/wiki/UTF-16).

Bref, c'est le gros mikmak, et ça n'a rien de joli joli.

[Franck.H]

Mouais effectivement, en fait c'était pour améliorer ma bibliothèque de chaînes de caractères et j'aurais voulu proposer la gestion des chaînes avec les wchar_t mais je caressais l'espoir qu'on puisse utiliser ce type aussi pour l'unicode etc.

Proposer l'un et l'autre séparément ça va être trop de travail pour peut-être pas grand chose car j'ai plus de 60 fonctions sans compter le fait que la libs est basée sur un objet (structure)... encore que là je pourrais m'en sortir avec un enum et permettre de créer un objet soit en char ou en wchar_t... à méditer

[Zenol]

Si tu veux rajouter le support d'UTF-8, je te conseil de rajouter un champ encodage dans ta structure, de la forme enum {ISO_8859_1, UTF-16}, et de fournir des fonctions de convertions. Certaines fonctions ne demanderont aucun changement (nombre de mots par exemple), d'autres en demanderont (nombre de caractères). Voire, ne pas mettre d'enum et modifier tes fonctions pour ne travailler qu'avec de l'UTF-16.

Je te déconseille de faire quelque chose de la forme enum {ISO_8859_1, UTF_8, UTF_16LE, UTF_16BE, etc...}, car ca là, même la fonction qui compte le nombre de lettre deviendrais horible. Le plus simple est vraiment de fournir des fonctions de conversions (from_utf_16le, from_utf_8, from_latin1, et to_utf_16le, to_utf_8le, etc...) et de ne travailler en interne qu'avec deux (voire un seul) format. C'est ce que font bon nombre de libs.

C'est un gros boulot, mais le jeux en vaut la chandelle. Ne serait-ce que pour pouvoir travailler avec des langues comme le japonnais.