Abandonner les char au profit des wchart_t

Tous les exemples de la FAQ (ou presque) ainsi que tous les tutoriaux utilisent des char et des std::string.
Pareil pour les iostream. Par défaut c'est fait pour gérer du texte, à condition qu'il soit en en "char" (on va dire "codé sur 8 bits").

J'essaie de porter mes programmes en unicode afin de laisser tomber définitivement (?) les char et string au profit des wchar_t et wstring. Je pensais la tâche relativement simple puisque les os (enfin, Windows) fonctionnent en unicode en interne. Pareil pour les langages comme Java, C#, l'interface COM, etc.
Je suis donc en train de changer les char en _TCHAR, les "..." en _T("..."), les string en _tstring (j'en ai fait un #define), les strxxx en _tcsxxx, etc, afin de pouvoir compiler à ma guise en _MBCS ou en _UNICODE.

Il s'avère que le C++ ne propose pas grand chose pour nous y aider... Pire, il nous met des batons dans les roues.
Ainsi par exemple pour ouvrir un fichier en utilisant wifstream() le nom de fichier passé en paramètre doit être une chaîne en... char et non pas wchar_t (aberrant je trouve 8O).
Autre exemple, les exceptions sont en char, pas en wchar_t (le fameux what() retourne un const char *).
"Officiellement", la norme C++ dit que wchar_t est au moins aussi grand que char, rien de plus. wchart_t n'est donc pas nécessairement un caractère sur 16 bits (même si en pratique je crois qu'il y a un consensus pour que se soit quand même le cas sur toute les plateformes, sauf peut-être sur les mac ?).

Bref, comment faire afin d'éviter la moindre conversion interne WideCharToMultiByte et vice versa ?
Merci pour vos expériences.

Et ca se complique encore quand tu utilises des librairies externes... Les char sont un peu partout, parfois en tant que représentation de caractères, parfois juste comme "unité minimale". Un changement brutal (à coup de define) peut entrainer des catastrophes, un portage manuel peut prendre un temps fou...

Pareil pour Windows, d'ailleurs, vu de loin, ou des COM, c'est du WideString, mais dès que tu regarde l'API...

J'ai l'impression que les w_char font partie, avec les valarray de la STL et quelques autres belles idées, de ces zones du standard pas tout à fait abouties, ou en tous cas pas assez utilisées pour être recommandables...

Si l'utilisation que tu fais des chaines est limitée à l'affichage et la recherche de sous chaines, une bonne solution intermédiaire est l'UTF8. A l'intérieur de ton programme, ça reste des char, leur interprétation en "caractères exotiques" n'étant faite qu'en toute fin de parcours... J'ai l'impression que c'est d'ailleurs ce que font pas mal de programmeurs qui doivent travailler avec des langues multioctets.

Francois

Salut,

Citation:

---

Envoyé par fcharton

J'ai l'impression que les w_char font partie, avec les valarray de la STL et quelques autres belles idées, de ces zones du standard pas tout à fait abouties, ou en tous cas pas assez utilisées pour être recommandables...

---

Disons, qu'à l'époque, la problématique n'était pas mûre non plus. Je ne pense pas dire beaucoup de bêtise en disant que dans les années 90 les chaînes de caractères étaient majoritairement gérées par des char y compris côté système.
Mais, effectivement, les chaînes de caractères, ça fait partie des choses assez pénibles à gérer en C++ et je ne connais pas de solution idéale.

Citation:

---

Envoyé par camboui

"Officiellement", la norme C++ dit que wchar_t est au moins aussi grand que char, rien de plus. wchart_t n'est donc pas nécessairement un caractère sur 16 bits (même si en pratique je crois qu'il y a un consensus pour que se soit quand même le cas sur toute les plateformes, sauf peut-être sur les mac ?).

---

Code:

---

1 2 3 4 5 6

#include <iostream>   int main() { std::cout << sizeof(wchar_t) << std::endl; }

---

--> 4 chez moi (linux)

D'ailleurs, il me semble que pour gérer tout l'unicode, il faut effectivement 32 bits par caractères (si tous les caractères font la même taille). Je ne sais pas comme fait windows (puisqu'avec visual, sizeof(wchar_t)==2) pour gérer les caractères qui ne tiennent pas en 2 octets.

Citation:

---

Bref, comment faire afin d'éviter la moindre conversion interne WideCharToMultiByte et vice versa ?
Merci pour vos expériences.

---

Pas vraiment de solution miracle. Mais j'irais un peu plus loin que toi, en rajoutant que non seulement, C++ est pénible pour ce qui est de l'unicode, mais il est pénible pour ce qui est de l'encodage en général : les fonctions de la libc sont dépendantes de la locale courante, et une vraie plaie à utiliser en multithread (et tu n'as aucune garantie qu'une locale est installée sur le système), d'où la nécessité de passer par une lib (comme iconv, par exemple).

Si tu t'intègres à un framework comme Qt et GTK, tout devient beaucoup plus simple : la gestion des encodages y est intégrée. Mais sinon...

Citation:

---

Envoyé par camboui

"Officiellement", la norme C++ dit que wchar_t est au moins aussi grand que char, rien de plus. wchart_t n'est donc pas nécessairement un caractère sur 16 bits (même si en pratique je crois qu'il y a un consensus pour que se soit quand même le cas sur toute les plateformes, sauf peut-être sur les mac ?).

---

C'est plutôt l'inverse, à part sur Windows où wchar_t fait 16 bits, il y a plus ou moins consensus ailleurs pour que wchar_t fasse 32 bits !

Citation:

---

Envoyé par white_tentacle

D'ailleurs, il me semble que pour gérer tout l'unicode, il faut effectivement 32 bits par caractères (si tous les caractères font la même taille). Je ne sais pas comme fait windows (puisqu'avec visual, sizeof(wchar_t)==2) pour gérer les caractères qui ne tiennent pas en 2 octets.

---

Windows, pour des raisons historiques, a d'abord fonctionné en USC-2, puis maintenant en UTF-16.

Je ne crois pas que ça soit la bonne méthode de tout faire à coup de #define et advienne que pourra.

Bon je vais pas pouvoir te donner trop de conseils, vu que je n'utilise que des version récentes de Linux pour mes GUI et que Linux gère très bien tout seul la gestion de chaînes UTF-8 à partir de std::strings.

Je ne sais pas où est le consensus exactement, puis que Java aussi bosse en UTF-16.

D'un autre côté, quand on ajoute les accents, même UTF-32 ne peut représenter un caractère dans un seul wchar_t (même si un code point dans un seul wchar_t, c'est déjà un progrès).

Citation:

---

Envoyé par white_tentacle

D'ailleurs, il me semble que pour gérer tout l'unicode, il faut effectivement 32 bits par caractères (si tous les caractères font la même taille). Je ne sais pas comme fait windows (puisqu'avec visual, sizeof(wchar_t)==2) pour gérer les caractères qui ne tiennent pas en 2 octets.

---

Comme pour le 8 bits... Avec des pages de code (ou parfois des polices). Il faut dire que 16 bits, c'est "presque assez" pour tout l'Unicode. En gros, tant que ton programme ne gère pas les langues Mycéniennes, ou les caractères chinois sur os (jiaguwen), tu ne crains pas grand chose...

Comme ces caractères anciens et rares sont plus souvent lus qu'écrits, on utilise parfois des scans. Sur certains sites, on a des polices spécifiques.

Pour un bon exemple du type de problème rencontré, et des solutions qu'on y apporte, tu peux regarder chant.org. C'est une base de donnée qui recense toutes les inscriptions chinoises anciennes découvertes, avec donc pas mal de signes qui n'existent qu'en un exemplaire... Il y a un peu d'explication en anglais sur leur site.

Francois

Des pages de codes? Surement pas!
Windows n'utilise pas de pages de codes pour l'Unicode, seulement du bon vieil UTF-16 (enfin bien sûr, quand on convertit en 8 bits, les pages de codes reviennent).

Pour les polices, c'est un tout autre problème: C'est juste qu'aucune police ne contient tout (Arial Unicode MS est une des plus complètes, mais elle est livrée avec Office, pas Windows).

Merci pour vos avis. Il n'y a donc pas de solution simple :cry:
Il n'y a même pas de cohérence avec wchar_t dont la taille est tantôt sur 16bits tantôt sur 32... Quelle gaspillage de place quand on n'en a pas l'utilité ! (je doute qu'on soit nombreux sur le forum à avoir besoin des 32 bits :roll:)

Mais il me faut bien faire un choix donc je vais adopter la méthode MS qui consiste à mettre des TCHAR partout puis de compiler au choix avec _MBCS ou _UNICODE. Cela devrait permettre de passer facilement de l'un à l'autre, mais à priori je vais continuer avec le char, l'encodage ISO8859-1 ou la CP1252 ayant comblé 100% de mes besoins jusqu'à présent.

Au passage, n'oublie pas quelques considérations:

• Un caractère ISO-8859-1 peut être casté en wchar_t, mais pas un caractère Windows-1252. Donc, penser à utiliser des fonctions de conversion
• Une console utilise de l'IBM-850 en France et de l'IBM-437 aux États-Unis.
• Plutôt que des #ifdef/#else/#endif pour les parties n'acceptant que des char ou des wchar_t (comme COM), n'oublie pas que tu codes en C++: La surcharge est ton amie.

Et bien merci pour tous ces avis et conseils. Je me suis plongé dedans.
Je souffre :cry: ;)

Question quand même à ceux qui ont un sizeof(wchar_t)==4.
Sachant que sizeof("abc")==4, que donne sizeof(L"abc") ?
Sous visual (et donc windows) ça donne 8. Est-ce que ça donne 16 pour ceux dont wchar_t est codé sur 4 bytes ?

la seule solution que j'ai trouvé (bon j'ai pas fait des masses recherche, j'avais pas le temps, je devais me faire juste un petit programme pour utiliser la libiconv sous windows) c'est de proscrire l'utilisation des chaines gérées par la stl. j'ai tout passé par les fonctions fournis par windows.

Citation:

---

Envoyé par camboui

Et bien merci pour tous ces avis et conseils. Je me suis plongé dedans.
Je souffre :cry: ;)

Question quand même à ceux qui ont un sizeof(wchar_t)==4.
Sachant que sizeof("abc")==4, que donne sizeof(L"abc") ?
Sous visual (et donc windows) ça donne 8. Est-ce que ça donne 16 pour ceux dont wchar_t est codé sur 4 bytes ?

---

Oui, ça donne 16.

Effectivement, les CString sont un moyen simple, sous windows, de se passer de ce genre de problèmes. De même que les QString de Qt.