Discussion :

[wistiti1234]

Bonjour,

Malgré les bribes d'informations que je lis ci et là, j'ai du mal a cerner la différence exacte entre le sdt::wstring et le Glib::ustring.

lorsque je code

Code :

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

1
2
3
4
5
 
std::wstring ch1 = L"aeé";
Glib::ustring ch2 = "aeé";
std::cout << std::hex << ch1[2] << std::endl;
std::cout << ch2[2] << std::endl;

Tout les deux me répondent le code hexa unicode du 'é': e9.

Pourtant je croyais que ustring était spécialiste de l'utf-8 (chez moi tout est utf-8: système, éditeur et console) donc je m'attendais plutôt, mais je suis peut-être à côté de la plaque, qu'il me réponde c3a9.
D'autre part, j'ai cru comprendre que le wstring ne gérait que des caractères à taille fixe, qu'il lisait un caractère tout les 1, 2, 3 ou 4 octets à chaque fois, mais pas un mélange. Or mon éditeur étant utf-8, dans "aeé" je vois 1 octet, 1 octet et 4 octets (je suis sous linux, je compile avec gcc 4.2.2). Pourtant wstring n'a pas l'air déstabilisé lorsque je lui demande de sortir le 3ime caractère de la chaîne.

En attendant je suis embêté par ce que la seule façon de voire s'afficher un 'é' sur ma console de sortie semble de lui envoyer c3a9. Je pensais que Glib::ustring en était capable, mais visiblement non.
Même

Code :

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

1
2
 
std::cout << ch2 << std::endl

se termine par un échec:

terminate called after throwing an instance of 'Glib::ConvertError'
Abandon

Pour l'instant je vois seulement std::string capable de m'envoyer ces octets tel quel et de m'afficher un 'é' correcte, seulement avec un string je ne peut pas extraire des caractères individuellement.


Comme vous le voyez, mon esprit est très embrouillé sur ces notions, et malheureusement, sur ce point précis, internet ne regorge pas d'informations détaillés et accessibles.
Alors j'ai espoir que quelqu'un par ici se donnera la peine d'éclaircir mes idées.

D'avance merci.

[teuf13]

Tout les deux me répondent le code hexa unicode du 'é': e9.

Pourtant je croyais que ustring était spécialiste de l'utf-8 (chez moi tout est utf-8: système, éditeur et console) donc je m'attendais plutôt, mais je suis peut-être à côté de la plaque, qu'il me réponde c3a9.

http://gtkmm.org/docs/glibmm-2.4/doc...813226d4d11351

l'operateur [] de ustring renvoie un objet de type "value_type", qui est un typedef pour gunichar qui correspond à un caractère unicode, donc ce que tu obtiens est normal

D'autre part, j'ai cru comprendre que le wstring ne gérait que des caractères à taille fixe, qu'il lisait un caractère tout les 1, 2, 3 ou 4 octets à chaque fois, mais pas un mélange. Or mon éditeur étant utf-8, dans "aeé" je vois 1 octet, 1 octet et 4 octets.

Un 'é' en utf-8 est codé sur 2 octets sauf erreur de ma part.

En attendant je suis embêté par ce que la seule façon de voire s'afficher un 'é' sur ma console de sortie semble de lui envoyer c3a9. Je pensais que Glib::ustring en était capable, mais visiblement non.
Même

Code :

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

1
2
 
std::cout << ch2 << std::endl

se termine par un échec:

Bizarre ton erreur... Ta console affiche en UTF-8 aussi ?

Comme vous le voyez, mon esprit est très embrouillé sur ces notions, et malheureusement, sur ce point précis, internet ne regorge pas d'informations détaillés et accessibles.

Tu as lu le paragraphe "Glib::ustring and stream input/output" de http://gtkmm.org/docs/glibmm-2.4/doc..._1ustring.html ?

[wistiti1234]

http://gtkmm.org/docs/glibmm-2.4/doc...813226d4d11351

l'operateur [] de ustring renvoie un objet de type "value_type", qui est un typedef pour gunichar qui correspond à un caractère unicode, donc ce que tu obtiens est normal

Ça veut dire quoi, que dans la mémoire physique il y a bien des octets UTF-8 mais que quand j'en sort un par [], il me les convertie en code unicode? Il n'est donc pas possible de "voire" directement ce qu'il y a en mémoire derrière un ustring?

http://gtkmm.org/docs/glibmm-2.4/doc...813226d4d11351
Un 'é' en utf-8 est codé sur 2 octets sauf erreur de ma part.

Oui enfin là aussi je suis un peu embrouillé.
Lorsque je fais un sizeof('é') il me répond 4 par ce que je crois qu'il prend un int et que le int vaut 4 octets sous Linux. Maintenant dans une chaîne je sais pas trop combien de place ça doit prendre.

http://gtkmm.org/docs/glibmm-2.4/doc...813226d4d11351
Bizarre ton erreur... Ta console affiche en UTF-8 aussi ?

C'est bon. J'avais oublié (ou plutôt je savais pas qu'il fallait mettre) la ligne setlocale(LC_ALL,""); dans mon programme.
Ça fonctionne maintenant.

http://gtkmm.org/docs/glibmm-2.4/doc...813226d4d11351
Tu as lu le paragraphe "Glib::ustring and stream input/output" de http://gtkmm.org/docs/glibmm-2.4/doc..._1ustring.html ?

Oui j'avais lu cette doc mais ça m'avait pas aidé. Comme dit plus haut, je savais pas qu'il fallait mettre le setlocale.
Mais même, je ne comprends toujours pas bien quels sont les avantages d'ustring sur wstring et dans quel cas il faut utiliser l'un et pas l'autre ou inversement.
Pour ça j'aimerais vraiment approfondir ce sujet et comprendre comment ces chaîne fonctionne au niveau des bits. Mais il est difficile de trouver une explication accessible mais approfondie sur ce sujet sur le net.

Quand je disais

D'autre part, j'ai cru comprendre que le wstring ne gérait que des caractères à taille fixe, qu'il lisait un caractère tout les 1, 2, 3 ou 4 octets à chaque fois, mais pas un mélange.

Je faisais justement référence à ceci

In a perfect world the C++ Standard Library would contain a UTF-8 string class. Unfortunately, the C++ standard doesn't mention UTF-8 at all. Note that std::wstring is not a UTF-8 string class because it contains only fixed-width characters (where width could be 32, 16, or even 8 bits).

dans la doc glibmm. Pourtant wstring n'a pas l'air d'avoir de problème à gérer ma chaîne. Je sais pas à quel niveau les problèmes commenceront à apparaître. C'est ça que j'aimerais savoir.

[teuf13]

Ça veut dire quoi, que dans la mémoire physique il y a bien des octets UTF-8 mais que quand j'en sort un par [], il me les convertie en code unicode? Il n'est donc pas possible de "voire" directement ce qu'il y a en mémoire derrière un ustring?

Oui, la ustring stocke les données en interne en utf-8, et l'opérateur [] te convertit ça en caractère unicode. Cf les méthodes décrites dans "Get a per-byte representation of the string." pour voir ce qui est stocké en mémoire.

Mais même, je ne comprends toujours pas bien quels sont les avantages d'ustring sur wstring et dans quel cas il faut utiliser l'un et pas l'autre ou inversement.

avec gtkmm, il vaut mieux utiliser la ustring, avec une wstring tu vas avoir des problèmes dés que t'as besoin d'une chaîne UTF-8. gtkmm fait peut être la convertion qui va bien automatiquement, mais c'est plus naturel d'utiliser des ustring. Et dés que tu voudras interagir avec du code C qui veut de l'UTF-8, ça risque d'être le bazar.
Et si ta wstring utilise 4 octets par caractère, ça fait généralement un gros gaspillage de mémoire... Enfin voilà quelques arguments en faveur des ustring