string et unicode

[bioinfornatics]

Je souhaitais savoir pourquoi Glib::ustring ne remplace pas les std::wstring en norme standard dans le futur?
Personnellement je trouve les Glib::ustring beaucoup plus pratique que les std::wstring.
Pouquoi réfuter son intégration? alors que tous les languages modernes intègrent naturellemnt l'unicode! Les Glib::ustring ne sont ils pas une solution efficace?

[koala01]

Salut,

Je ne connais pas bien Glib::ustring, mais, peut-être n'est-ce que parce que... cette classe ne présente pas la même interface que std:w)string.

Il faut comprendre que, de façon tout à fait générale, il y a un grand principe qui prédomine énormément au moment de faire évoluer la norme: il faut assurer une compatibilité aussi importante que possible avec le code ancien.

En effet, lorsqu'un langage largement utilisé existe depuis une bonne vingtaine d'années, on peut estimer que des millions, si pas des milliards de lignes de code ont été écrite de par le monde.

Si on apporte des changements trop importants à l'existant, cela risque de nécessiter énormément de modifications dans ces lignes de code, surtout si la modification touche à quelque chose d'aussi classique que... les chaines de caractères.

De plus, il ne faut pas oublier que le propre du C++ est... de pouvoir s'adapter à de nombreux systèmes d'exploitation et d'architectures.

Tous ne sont pas forcément capables d'utiliser glib

[bioinfornatics]

oui je comprend bien le problème de la compatibilité descendante mais pourquoi pas mettre un nouveau type ustring dans std et de laisser wstring (le mettre en deprecated )

[3DArchi]

Salut,
Il me semble que c'est le but des u16string (basic_string<char16_t>) et u32string (basic_string<char32_t>) introduits, non ?

[bioinfornatics]

je cite:

Envoyé par Glib::ustring

Glib::ustring vs. std::string
Glib::ustring has implicit type conversions to and from std::string. These conversions do not convert to/from the current locale (see Glib::locale_from_utf8() and Glib::locale_to_utf8() if you need that). You can always use std::string instead of Glib::ustring*-- however, using std::string with multi-byte characters is quite hard. For instance, std::string::operator[] might return a byte in the middle of a character, and std::string::length() returns the number of bytes rather than characters. So don't do that without a good reason.
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).

soit les wstring et apparemment les u16string et u32string sont des tailles fixe d'ou une consomation de mémoire. Ce qui n'est pas le cas des ustring pourquoi inventer la roue et faire moins bien!

[Klaim]

Définis "moins bien" voir?

[bioinfornatics]

moins bien par rapport a que j'ai cité précédement

[Klaim]

Ca n'explique pas grand chose.

Une discussion en rapport :
http://www.developpez.net/forums/d93...string-length/

[JolyLoic]

pourquoi inventer la roue et faire moins bien!

Parce qu'un seul modèle de roue ne marche pas bien pour un vélo, une voiture et une trottinette. Et parce que la roue en question est un peu voilée...


Pour avoir utilisé Glib::ustring sur un vrai projet, je peux dire que je suis bien content d'avoir std::wstring...

Tout d'abord, en terme d'encodage, utf-8 n'est pas la panacée. Dans mon environnement, les caractères servant à coder des langues asiatiques utiles pour l'archéologie, on n'est pas concerné. Donc des wstring sur 16 bit suffisent à tout encoder avec 1 emplacement par caractère, et jamais plus. Et du coup, les traitement se font de manière plus rapide qu'avec un Glib::ustring qui doit sans cesse faire des calculs pour savoir si un caractères est mono-octet ou pas. On utilise par contre souvent des Glib::ustring pour le stockage (et on sait qu'on ne sera pas très bon pour certaines langues).

De plus, en dehors de l'encodage, en terme d'interface, Glib::ustring présente quelques choix qui sont douteux. Par exemple, la conversion implicite en std::string qui ne prend pas en compte la locale courante est une source de bugs non négligeable.

Le fait qu'ustring soit non templatée (donc non configurable) est aussi problématique. Comment écrire un ustring qui soit non case-sensitive ? Ou un ustring alloué en mémoire partagée ?

Et enfin, la license associée à Glib::ustring, trop restrictive, ne permettrait pas son introduction dans un standard.


PS : La doc que tu cites ne mentionne pas les u16string et u32string, puisqu'il n'existent pas encore. Mais ces deux types sont bien à encodage variable.