Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 9 sur 9

Discussion: string et unicode

  1. #1
    Membre éprouvé

    Profil pro Jonathan MERCIER
    Inscrit en
    mars 2009
    Messages
    349
    Détails du profil
    Informations personnelles :
    Nom : Jonathan MERCIER
    Localisation : France, Gironde (Aquitaine)

    Informations forums :
    Inscription : mars 2009
    Messages : 349
    Points : 408
    Points
    408

    Par défaut string et unicode

    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?

  2. #2
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 686
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 686
    Points : 15 737
    Points
    15 737

    Par défaut

    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
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  3. #3
    Membre éprouvé

    Profil pro Jonathan MERCIER
    Inscrit en
    mars 2009
    Messages
    349
    Détails du profil
    Informations personnelles :
    Nom : Jonathan MERCIER
    Localisation : France, Gironde (Aquitaine)

    Informations forums :
    Inscription : mars 2009
    Messages : 349
    Points : 408
    Points
    408

    Par défaut

    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 )

  4. #4
    Rédacteur/Modérateur
    Avatar de 3DArchi
    Inscrit en
    juin 2008
    Messages
    7 636
    Détails du profil
    Informations forums :
    Inscription : juin 2008
    Messages : 7 636
    Points : 11 688
    Points
    11 688

    Par défaut

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

  5. #5
    Membre éprouvé

    Profil pro Jonathan MERCIER
    Inscrit en
    mars 2009
    Messages
    349
    Détails du profil
    Informations personnelles :
    Nom : Jonathan MERCIER
    Localisation : France, Gironde (Aquitaine)

    Informations forums :
    Inscription : mars 2009
    Messages : 349
    Points : 408
    Points
    408

    Par défaut

    je cite:
    Citation 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!

  6. #6
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 1 717
    Points : 3 026
    Points
    3 026

    Par défaut

    Définis "moins bien" voir?

  7. #7
    Membre éprouvé

    Profil pro Jonathan MERCIER
    Inscrit en
    mars 2009
    Messages
    349
    Détails du profil
    Informations personnelles :
    Nom : Jonathan MERCIER
    Localisation : France, Gironde (Aquitaine)

    Informations forums :
    Inscription : mars 2009
    Messages : 349
    Points : 408
    Points
    408

    Par défaut

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

  8. #8
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 1 717
    Points : 3 026
    Points
    3 026

    Par défaut

    Ca n'explique pas grand chose.

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

  9. #9
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro Loïc Joly
    Développeur informatique
    Inscrit en
    août 2004
    Messages
    4 953
    Détails du profil
    Informations personnelles :
    Nom : Homme Loïc Joly
    Âge : 40
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 4 953
    Points : 11 235
    Points
    11 235

    Par défaut

    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.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •