Discussion :

[koala01]

Salut,

Pour une fois, j'ouvre une discussion, car je me pose réellement une question...

Avant la nouvelle norme, std::exception ne fonctionnait qu'avec des char "8 bits".

La nouvelle norme a décidé d'ajouter des traits pour les char "16 bits" et pour les char "32 bits", afin d'améliorer le support des différentes formes d'UTF.

Si bien que l'on peut "assez facilement" prévoir son code pour qu'il s'adapte aux différentes tailles de caractères avec un code plus ou moins proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#include <string>
#include <iosfwd>
#if defined(USE_UTF32)
    #define LITTERAL(X) U("##x##")
    typedef char32_t CHAR_T;
#elif defined(USE_UTF16)
        #define LITTERAL(X) u("##x##")
        typedef char16_t CHAR_T;
#else
#define USE_UTF8
#endif
#if defined(USE_UTF8)
#define LITTERAL(X) u8("##x##")
typedef char CHAR_T;
#endif
typedef std::basic_string<CHAR_T> string;
 
typedef std::basic_istringstream<CHAR_T> istringstream;
 
typedef std::basic_ostringstream<CHAR_T> ostringstream;
 
typedef std::basic_stringstream<CHAR_T> stringstream;

Je n'ai parcouru la nouvelle norme qu'en diagonale, mais je n'ai rien vu quant à un éventuel support de l'UTF en ce qui concerne les exceptions

Le probème, si une exception doit etre lancée, c'est qu'il faudra reconvertir la chaine de caractères en std::string, pour, sans doute, la reconvertir en std::basic_string<CHAR_T> afin de pouvoir afficher le message d'erreur

Ma question est donc : ai-je vraiment mal cherché, ou est ce que les exceptions restent effectivement exclusivement prévues pour fonctionner avec des char 8 bits

Dans la deuxième hypothèse, est-ce que quelqu'un sait quelle a été la motivation du comité pour ne pas les élagir au suport de l'UTF

[Klaim]

A ce que je sache, au final la taille des données n'a rien a voir avec l'encodage choisis (UTF-8,16 ou 32 ou autres).

Donc que l'interface expose char ou wchar_t, ça ne donne strictement aucune guarantie sur l'encodage.

Donc je vois pas bien ce que ça changerai pour toi?

[JolyLoic]

Si bien que l'on peut "assez facilement" prévoir son code pour qu'il s'adapte aux différentes tailles de caractères avec un code plus ou moins proche de

[snip]
Je ne suis pas convaincu que ce soit une si bonne manière de faire... Mais je n'ai pas forcément mieux à proposer
Je préfère généralement avoir au cœur de mon programme un seul type de chaîne de caractères, décidé une bonne fois pour toutes, et par contre, aux frontières (lecture/écriture de ficheirs, par exemple, mais aussi envoi sur le réseau...) de gérer explicitement l'encoding (ou plutôt les encodings) pris en compte.

Ma question est donc : ai-je vraiment mal cherché, ou est ce que les exceptions restent effectivement exclusivement prévues pour fonctionner avec des char 8 bits

Je pense que tu as bien cherché.

Dans la deuxième hypothèse, est-ce que quelqu'un sait quelle a été la motivation du comité pour ne pas les élagir au suport de l'UTF

Elle supportent donc déjà UTF-8
Globalement, le support de différents encodage était perçu comme quelque-chose de très complexe, et pour laquelle on manquait globalement d'expérience (ou plutôt, il y avaient plein d'expériences individuelles, qui divergeaient, mais pas de consensus).

Quand on regarde bien, même si de nouveaux types de caractères ont été introduits, rien n'a été fait pour y adapter basic_string (par exemple, que signifie le 3ème caractère dans une chaîne UTF-8 ? L'opérateur [] ne devrait-il par retourner un groupe de char_type ?), ni vraiment les flux (c'est toujours aussi complexe de dire qu'un flux doit utiliser une certaine locale pour écrire).

Je pense que l'introduction de ces types avait plus pour but de permettre à des personnes dans le domaine de développer des bibliothèques mieux intégrées qu'elles ne l'étaient auparavant, et puis au prochain tour de standardisation, on verra ce qu'il y a. C'est dommage...

Maintenant, pour les exceptions, ce n'est pas forcément un gros problème : Soit tu décides qu'elles doivent contenir un texte purement technique à usage interne, et dans ce cas là, l'encodage de base suffit bien, soit tu considères qu'elles doivent contenir un texte destiné à l'utilisateur final, et dans ce cas, le résultat de what() est plus à considérer comme un identificateur qui te permettra de trouver le bon message dans la bonne langue et le bon encodage au moment de l'afficher, et pour cet identificateur, l'encodage de base suffit bien.

[Klaim]

Je pense que l'introduction de ces types avait plus pour but de permettre à des personnes dans le domaine de développer des bibliothèques mieux intégrées qu'elles ne l'étaient auparavant, et puis au prochain tour de standardisation, on verra ce qu'il y a.

Comme par exemple: http://www.open-std.org/jtc1/sc22/wg...012/n3398.html

[koala01]

A ce que je sache, au final la taille des données n'a rien a voir avec l'encodage choisis (UTF-8,16 ou 32 ou autres).

Donc que l'interface expose char ou wchar_t, ça ne donne strictement aucune guarantie sur l'encodage.

Donc je vois pas bien ce que ça changerai pour toi?

Si ce n'est que, dans le cas de l'UTF16 ou de l'UTF32, tu ne peux (à moins que je n'aie vraiment mal compris leur mode de fonctionnement) pas avoir la certitude qu'il n'y aura jamais 8 bits représentant une valeur nulle, qui serait alors considéré, avec un char 8bits, comme étant... la fin de la chaine.

Cela pourrait entrainer des conséquences plus ou moins facheuses dans certaine situations, non

[snip]
Je ne suis pas convaincu que ce soit une si bonne manière de faire... Mais je n'ai pas forcément mieux à proposer
Je préfère généralement avoir au cœur de mon programme un seul type de chaîne de caractères, décidé une bonne fois pour toutes, et par contre, aux frontières (lecture/écriture de ficheirs, par exemple, mais aussi envoi sur le réseau...) de gérer explicitement l'encoding (ou plutôt les encodings) pris en compte.

Tout dépend de ce que tu veux faire...

Pour n'importe quelle application "classique", j'aurais aussi également tendance à privilégier l'utilisation de la std::string pour la partie métier.

Mais, dans le cadre d'une bibliothèque IHM, par exemple, il peut etre intéressant de définir un encodage "global", adapté à l'utilisation qui en est faite, à la compilation, non

Je pense que tu as bien cherché.

Merci pour la confirmation

Elle supportent donc déjà UTF-8

Fatalement

Globalement, le support de différents encodage était perçu comme quelque-chose de très complexe, et pour laquelle on manquait globalement d'expérience (ou plutôt, il y avaient plein d'expériences individuelles, qui divergeaient, mais pas de consensus).

Quand on voit la difficulté qu'il peut y avoir à trouver des informations pertinentes et non contradictoires sur le sujet et les problèmes auxquels on est confrontés rien que pour faire afficher correctement les accents sous windows, cela n'a, malheureusement, pas grand chose d'étonnant :p

Quand on regarde bien, même si de nouveaux types de caractères ont été introduits, rien n'a été fait pour y adapter basic_string (par exemple, que signifie le 3ème caractère dans une chaîne UTF-8 ? L'opérateur [] ne devrait-il par retourner un groupe de char_type ?), ni vraiment les flux (c'est toujours aussi complexe de dire qu'un flux doit utiliser une certaine locale pour écrire).

Je comprends bien...

C'est, quelque part, le sens de ma question : j'ai l'impression que le comité s'est, plus ou moins, arrêté à mi chemin en fournissant les traits, mais que c'était malgré tout une étape indispensable à la suite

Je pense que l'introduction de ces types avait plus pour but de permettre à des personnes dans le domaine de développer des bibliothèques mieux intégrées qu'elles ne l'étaient auparavant, et puis au prochain tour de standardisation, on verra ce qu'il y a. C'est dommage...

Tout à fait...

Mais, encore une fois, j'ai l'impression que c'était une étape indispensable avant d'envisager d'aller plus loin

Maintenant, pour les exceptions, ce n'est pas forcément un gros problème : Soit tu décides qu'elles doivent contenir un texte purement technique à usage interne, et dans ce cas là, l'encodage de base suffit bien, soit tu considères qu'elles doivent contenir un texte destiné à l'utilisateur final, et dans ce cas, le résultat de what() est plus à considérer comme un identificateur qui te permettra de trouver le bon message dans la bonne langue et le bon encodage au moment de l'afficher, et pour cet identificateur, l'encodage de base suffit bien.

Pour l'usage exclusivement interne, je suis globalement d'accord...

Par contre, pour ce qui est des textes éventuellement destinés à l'utilisateur final, j'aurais plutôt tendance à considérer le résultat de what() comme faisant partie intégrante du message, à traduire éventuellement, mais à utiliser dans le "langage par défaut" (par exemple, pour le "titre" de la boite de dialogue affichant le problème survenu).

Si je comprend bien, tu considérerais plutot que je fais une erreur de conception dans ma manière d'envisager l'internationalisation (mais bon, je reste de toutes manières ouvert à toute critiques )

En tout cas, merci pour vos interventions

Je laisse la discussion ouverte pour laisser la chance à d'autres de s'exprimer

[Jean-Marc.Bourguet]

Depuis "toujours", le modèle de gestion des encodages en C et en C++, c'est qu'il y a un charset par locale, avec deux encodages, un "étroit" (narrow), utilisant les char comme unité de base, permettant des codes multibytes (i.e. un caractère est codé sur plusieur char) et modal (l'interprétation d'une séquence de char peut dépendre d'un état appelé shift state), et un "large" (wide), utilisant les wchar_t comme unité, code unibyte (tout caractère est codé par un seul wchar_t) et non modal (le caractère associé à un wchar_t donné est toujours le même). Il y a quelques contraintes sur ces encodages, en gros les caractères du jeu de base sont codés par un seul char, positif et le même dans toutes les locales, les chiffres sont codés par des valeurs consécutives en commençant à 0. Il est courant, mais pas universel, que les implémentations utilisent des sous-ensemble d'un seul encodage l'encodage large de toutes les locales. La formulation dans les normes est souvent malheureuse, ne distinguant pas clairement charset et encodage.

Ce qu'ajoute C11 et C++11, c'est char16_t et char32_t destiné à recevoir de l'UTF-16 (qui ne peut formellement pas être mis dans des wchar_t à cause de la contrainte unibyte, même si wchar_t fait 16 bits sur des plateformes - MS, IBM -- qui ont cru qu'Unicode tiendrait sa promesse de rester sur 16 bits alors qu'ISO 10646 prévoyait déjà plus) et de l'UTF-32 ainsi que des littéraux UTF8, UTF16 et UTF32 (les littéraux sont classiquement dans l'encodage d'une locale définie par l'implémentation, gcc par exemple a des options pour le définir). Il me semble pas qu'il y ait beaucoup plus, la difficulté étant en partie de définir un nouveau modèle plus en phase avec les pratiques et attentes actuelles et surtout de le rendre compatible avec l'ancien modèle. Il me semble qu'il y a un papier dans le dernier mailing traçant une voie, mais j'ai pas encore eu le temps de le lire.

[Jean-Marc.Bourguet]

ni vraiment les flux (c'est toujours aussi complexe de dire qu'un flux doit utiliser une certaine locale pour écrire).

On n'a pas dépassé le stade du début des années 90, on récupère dans l'environnement la locale et donc le charset à utiliser pour les IO et on récupère dans des fichiers tout ce qui est spécifique à ce charset ou on suppose que l'exécutable été compilé avec l'utilisation du bon charset pour cet environnement. Les conversions en dehors d'entre les deux encodages prévus pour ce charset sont totalement absentes. Il y a suffisamment de garantie pour indexer ces fichiers à partir de clés en ASCII.

Je connais très mal Windows, mais je crois qu'une partie des difficultés y est que le runtime ne fonctionne pas tel qu'il a été conçu (j'ai l'impression par exemple que la notion de locale est globale au système ou à l'utilisateur plutôt que propre à un processus) -- pour des bonnes ou de mauvaises raisons, j'en sais rien (d'où je suis, j'ai l'impression qu'il y a une confusion historique, ils se sont peut-être retrouvé coincé comme c'est arrivé avec le wchar_t sur 16 bits, quand ils ont vu plus clair).

Par contre, pour ce qui est des textes éventuellement destinés à l'utilisateur final, j'aurais plutôt tendance à considérer le résultat de what() comme faisant partie intégrante du message, à traduire éventuellement, mais à utiliser dans le "langage par défaut" (par exemple, pour le "titre" de la boite de dialogue affichant le problème survenu).

Je vois le what comme étant devant être écrit dans le jeu de base, en pratique ASCII sauf si tu travailles sur des mainframes IBM, ce qui est garanti avoir le même encodage étroit dans toutes les locales.