IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Contribuez C++ Discussion :

string et unicode


Sujet :

Contribuez C++

  1. #1
    Membre confirmé

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

    Informations forums :
    Inscription : Mars 2009
    Messages : 349
    Points : 590
    Points
    590
    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
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    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 confirmé

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

    Informations forums :
    Inscription : Mars 2009
    Messages : 349
    Points : 590
    Points
    590
    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
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Points : 13 017
    Points
    13 017
    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 confirmé

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

    Informations forums :
    Inscription : Mars 2009
    Messages : 349
    Points : 590
    Points
    590
    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
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    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 344
    Points
    3 344
    Par défaut
    Définis "moins bien" voir?

  7. #7
    Membre confirmé

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

    Informations forums :
    Inscription : Mars 2009
    Messages : 349
    Points : 590
    Points
    590
    Par défaut
    moins bien par rapport a que j'ai cité précédement

  8. #8
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    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 344
    Points
    3 344
    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
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    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 : 5 463
    Points : 16 213
    Points
    16 213
    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.
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

Discussions similaires

  1. Boucle while retour chariot string en unicode
    Par Nemesis007 dans le forum Développement
    Réponses: 2
    Dernier message: 03/10/2009, 17h37
  2. String et Unicode
    Par prgasp77 dans le forum Caml
    Réponses: 2
    Dernier message: 30/09/2009, 08h21
  3. Transformer une String en Unicode
    Par annemarie dans le forum Delphi
    Réponses: 3
    Dernier message: 28/02/2007, 18h43
  4. [C++] string en unicode ou ansi
    Par dug dans le forum C++
    Réponses: 13
    Dernier message: 02/02/2007, 21h08
  5. [C#] Convertir un string UNICODE => ASCII
    Par alex57 dans le forum Windows Forms
    Réponses: 1
    Dernier message: 10/09/2005, 21h32

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo