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
[Question] Difference entre 2 types (char et wchar_t)
Bonjour,
je cherche à differencier les 2 types suivant: char et wchar_t
J'ai regardé sur le forum...
http://<br /> http://c.developpez.c..._wstring<br />
Mais je n'ai pas trouvé satisfaction...
Connaissez vous la différence entre ces 2 types ?
Pourquoi préférer les char * ?
Ou au contraire préferer les wchar_t* ?
Merci pour vos avis ?
PS: Et vous vous utilisez lequel ? (ne me dites pas string ou wstring)
L'un est sur un octet, l'autre sur 2. Si tu dois manipuler des chaines unicode, wchart_t est là pour ça.
Ok et c'est la seule différence ?
J'ai lu que en c++ standard, le c++ transformait l'unicode en char simple ?
Je te cite:
Ou est donc l'interet ?Cependant, en ce qui concerne les fichiers, les caractères wchar_t sont convertis de manière transparente en char au moment de l'écriture. Le C++ standard ne permet pas en effet de manipuler des fichiers Unicode.
Merci !
PS: Chaine unicode ??
En effet, on ne peut pas lire les fichiers directement en mode texte.
Mais on peut utiliser l'unicode en interne, ou pour écrire sur une console sans avoir à convertir les caractères...
PS: Quelqu'un sait si wcout (la sortie standard unicode) marche avec code::blocks ? Il n'y a pas moyen de la faire marcher avec Dev-C++...
Faux. Sur un byte.L'un est sur un octet,
Faux. La taille de wchar_t n'est pas du tout spécifiée.l'autre sur 2.
C'est censé être suffisamment grand pour pouvoir contenir n'importe quel caractère supporté par le système.
Ce qui est assez problématique sous Windows, d'ailleurs, car ce n'est pas suffisamment grand pour contenir n'importe quel caractère Unicode.
Sur mon système (GNU/Linux), wchar_t fait 4 octets.
Non seulement il n'est pas là pour ça (aucune référence à Unicode n'est faite dans la définition de ce type) mais en plus l'utiliser pour cela serait à mon avis un mauvais choix vu les complications et les incompatibilités engendrées.Si tu dois manipuler des chaines unicode, wchart_t est là pour ça.
Le C++ standard n'a aucun concept de chaîne ANSI ou Unicode, ce sont des éléments inventés par l'api win32.
Pour gérer l'unicode je trouve que la meilleure manière est d'utiliser Glib::ustring.
comment traduis-tu byte en français ?Envoyé par loufoque
Je ne suis pas sûr que sizeof( char ) = 1 byte. De mémoire, la norme définit que sizeof( char ) == 1, tout court. Si sur ta machine 1 byte = 6 bits, je suppose que les chars sont codés sur 2 byte.
Sa taille est "implementation defined". Chez moi c'est 2, donc, comme dirait Perceval, c'est pas faux!Faux. La taille de wchar_t n'est pas du tout spécifiée.l'autre sur 2.
Windows est en UTF-16, et tous les caractères unicode sous cet OS font 2 octets (WCHAR). Donc tout va bien.C'est censé être suffisamment grand pour pouvoir contenir n'importe quel caractère supporté par le système.
Ce qui est assez problématique sous Windows, d'ailleurs, car ce n'est pas suffisamment grand pour contenir n'importe quel caractère Unicode.
Ca se discute. Si tu veux faire de l'Unicode sous Windows, ça convient très bien à mon avis. Après, vu que wchar_t est dépendant de l'implémentation, c'est pas une bonne idée pour du code portable. Mais peut-on faire une vraie appli unicode portable ?Non seulement il n'est pas là pour ça (aucune référence à Unicode n'est faite dans la définition de ce type) mais en plus l'utiliser pour cela serait à mon avis un mauvais choix vu les complications et les incompatibilités engendrées.Si tu dois manipuler des chaines unicode, wchart_t est là pour ça.
c'est un point, avec le "implementation defined", qui mérite d'être souligné dans la FAQ. On va parler de wide-string / wide-char au lieu de string/char unicode. Je note ta remarqueLe C++ standard n'a aucun concept de chaîne ANSI ou Unicode, ce sont des éléments inventés par l'api win32.
Il n'y a pas de "bonne" traduction à ma connaissance.
Un byte est l'espace mémoire adressable le plus petit. Enfin ça c'est la définition originale. Depuis que les bytes de 8 bits sont devenus si populaires, c'est vrai qu'on dit qu'un byte est 8 bits sauf mention contraire.
De plus, la définition du C/C++ dit qu'un byte doit faire au moins 8 bits, donc il se peut que ce soit en fait plusieurs bytes au niveau hardware.
sizeof fournit un résultat en bytes d'après la définition de byte de C/C++.Je ne suis pas sûr que sizeof( char ) = 1 byte. De mémoire, la norme définit que sizeof( char ) == 1, tout court. Si sur ta machine 1 byte = 6 bits, je suppose que les chars sont codés sur 2 byte.
sizeof(char) vaut toujours 1 byte car par définition, char vaut exactement un byte.
C'est ta botte secrète ?Sa taille est "implementation defined". Chez moi c'est 2, donc, comme dirait Perceval, c'est pas faux!
Unicode réserve 2^20 + 2^16 soit 1 114 112 caractères.Windows est en UTF-16, et tous les caractères unicode sous cet OS font 2 octets (WCHAR). Donc tout va bien.
Avec un entier de 16 bits, on ne peut représenter que 2^16 = 65 536 caractères différents.
Donc soit Windows ne peut pas gérer tous les caractères Unicode (donc ce ne serait pas de l'UTF-16 mais de l'UCS-2), soit il n'utilise pas ce type de façon appropriée (un caractère pourrait être codé sur deux entiers de 16 bits, c'est UTF-16).
Windows ne supporte qu'UCS-2 à cause d'un soucis historique. Avant 1999 Unicode ne réservait que 65 536 caractères.
(UCS-2 est la même chose qu'UTF-16 mais sans la possibilité d'avoir un caractère sur deux entiers, restreingnant du coup la plage de caractères possibles)
Je ne m'y connais pas vraiment en programmation windows mais la méthode de fonctionnement d'Unicode sous windows me parait inélégante.Ca se discute. Si tu veux faire de l'Unicode sous Windows, ça convient très bien à mon avis. Après, vu que wchar_t est dépendant de l'implémentation, c'est pas une bonne idée pour du code portable.
À ce que j'ai vu, y'a des macros partout (on définit tchar comme étant soit char soit wchar_t) et le code unicode n'est pas compatible avec le code ansi.
La bibliothèque à laquelle j'ai fait référence dans mon précédent message (qui fait partie de glibmm) est tout à fait portable, tout simplement parce qu'elle ne se base pas sur le système. C'est juste une implémentation de chaîne unicode qui utilise utf-8. Et ça se convertit facilement en std::string (conversion vers l'encodage local) ou std::wstring (passage à UCS-2 ou UCS-4 suivant la taille de wchar_t).Mais peut-on faire une vraie appli unicode portable ?
Ça fonctionne même sous Win9x où je crois bien qu'il n'y a pas les fonctionnalités unicode de Windows NT/2000/XP.
je crois que la bonne traduction de byte serait nuplet, mais octet est quasi officiel. Du coup, octet en français désigne byte et octet en anglaisIl n'y a pas de "bonne" traduction à ma connaissance.
Un byte est l'espace mémoire adressable le plus petit. Enfin ça c'est la définition originale. Depuis que les bytes de 8 bits sont devenus si populaires, c'est vrai qu'on dit qu'un byte est 8 bits sauf mention contraire.
De plus, la définition du C/C++ dit qu'un byte doit faire au moins 8 bits, donc il se peut que ce soit en fait plusieurs bytes au niveau hardware.
Les macros servent à écrire un code qui compile idifférement en ansi ou unicode. Tout est doublé : les types (CHAR/WCHAR, LPSTR/LPWSTR, ...) mais aussi et surtout les fonctions (GetWindowTextA/GetWindowTextW).Je ne m'y connais pas vraiment en programmation windows mais la méthode de fonctionnement d'Unicode sous windows me parait inélégante.Ca se discute. Si tu veux faire de l'Unicode sous Windows, ça convient très bien à mon avis. Après, vu que wchar_t est dépendant de l'implémentation, c'est pas une bonne idée pour du code portable.
À ce que j'ai vu, y'a des macros partout (on définit tchar comme étant soit char soit wchar_t) et le code unicode n'est pas compatible avec le code ansi.
GetWindowText n'existe pas, c'est une macro qui renvoie vers l'une des 2 implémentations. Sous NT, GetWindowTextA appelle GetWindowTextW après avoir converti la string ANSI reçue en UNICODE. Sous Win9x, c'est l'inverse. Ca c'est pour Win32.
En .Net tout est unicode.
En fait je me demande ce que ça donne de créer un fichier portant un nom unicode dans un charset non supporté par l'OS, ou simplement afficher un message unicode non supporté dans la console Windows... ce genre de problèmes quoi.La bibliothèque à laquelle j'ai fait référence dans mon précédent message (qui fait partie de glibmm) est tout à fait portable, tout simplement parce qu'elle ne se base pas sur le système. C'est juste une implémentation de chaîne unicode qui utilise utf-8. Et ça se convertit facilement en std::string (conversion vers l'encodage local) ou std::wstring (passage à UCS-2 ou UCS-4 suivant la taille de wchar_t).Mais peut-on faire une vraie appli unicode portable ?
Ça fonctionne même sous Win9x où je crois bien qu'il n'y a pas les fonctionnalités unicode de Windows NT/2000/XP.
Pour ça on convertit les données en "ANSI".En fait je me demande ce que ça donne de créer un fichier portant un nom unicode dans un charset non supporté par l'OS, ou simplement afficher un message unicode non supporté dans la console Windows... ce genre de problèmes quoi.
Multiplet.
Dans le cadre du C et du C++, sizeof(char) c'est bien un byte. C'est une définition en accord général avec l'utilisation traditionnelle de byte qui est un caractère, mais en désaccord avec les machines ayant des bytes de moins de 8 bits parce que ces normes imposent aussi qu'un byte fasse au moins 8 bits.Je ne suis pas sûr que sizeof( char ) = 1 byte. De mémoire, la norme définit que sizeof( char ) == 1, tout court. Si sur ta machine 1 byte = 6 bits, je suppose que les chars sont codés sur 2 byte.
Le seul cas que je connaisse où un compilateur C a existé, c'est le PDP-10 et le compilateur en question avait des modes ne respectant pas cette contrainte.
Non, un byte est l'espace nécessaire pour contenir un caractère. C'est le C et le C++ qui demandent qu'en plus il soit adressable. Ce qui est possible de deux manières sur les machines adressables par mot, soit on prend un
byte = un mot, soit on prend un byte = une partie de mot et on construit des pointeurs composés.
Je croyais que le PDP-10 avait des bytes de 36 bits, donc où est le problème ?
J'ai tenté de résumer nos discussions en une nouvelle question pour la FAQ:
Vos critiques sont les bienvenuesQuelle est la différence entre les type char et wchar_t ?
Le C++ possède deux types de caractères : le classique type char, dont la taille est définie comme faisant 1 byte (sizeof( char ) = 1), et le type caractère long (wide char) wchar_t dont la taille et le type réel sont laissés à la libre appréciation de chaque compilateur (implementation defined). Ainsi, avec Visual C++ sous Windows, wchar_t fait 2 octets, alors qu'avec g++ sous GNU/Linux il en fait 4.
Le type char de 8 bits (car un byte ne fait pas toujours 8 bits) est aussi appelé ANSI char, pour le différencier du wide char wchar_t. Etant donné que la plupart des machines modernes définissent la taille d'un byte à 8 bits, il est courant de parler d'ANSI string pour les char*, et de wide string pour les wchar_t* dans la terminologie purement C++. Comme les wide string ont généralement vocation à stocker des chaînes Unicode, on désigne aussi courament les wchar_t* par chaînes Unicode, bien que le standard n'ai pas cette notion.
Le C++ ne précise rien quant au système de codage de caractères (charset) associé à ces différents types de chaînes de caractères. En général, le type char sert à manipuler des caractères ASCII et le type wchar_t des caractères Unicode (dont le charset dépend de votre système / compilateur : UTF-16 sur 2 octets, UTF-32 sur 4...). Mais rien n'est définit par la norme. Celle-ci stipule simplement que char et wchar_t servent à stocker des caractères. Libre à vous de choisir le système d'encodage de ces derniers.
En général, votre programme va associer au type char le charset utilisé par la plateforme cible. Sur un ancien système IBM, char servira à manipuler des caractères EBCDIC. Sous Windows, il servira généralement à manipuler des caractères ASCII étendus (spécifiques à la langue en cours d'utilisation) mais aussi éventuellement des caractères OEM hérités de MS-DOS (typiquement pour afficher correctdement les accents dans la console).
Le PDP-10 est adressable par mot et a des mots de 36 bits effectivement. Mais les OS pour PDP-10 utilisaient des jeux de caractères (donc des bytes) de 6 (SIXBIT) ou 7 bits (ASCII) et mettaient donc 6 ou 5 (avec un bit unutilisé) caractères par mot.Je croyais que le PDP-10 avait des bytes de 36 bits, donc où est le problème ?
Le compilateur auquel je faisais allusion avait un switch pour choisir des bytes de 7, 8 ou 9 bits (http://www.dbit.com/pub/pdp10/kcc/cc.c pour voir la source). La seule position où il y a moyen de faire un compilateur conforme, c'est d'utiliser des bytes de 9 bits (il en faut au moins 8, et il ne faut pas de trous ce que des bytes de 7 ou 8 bits auront.
J'ai pas trop le temps maintenant, peut-être une fois les enfants couchés (il n'y pas moyen de marquer un message comme nécessitant un retour?). Mais je ne suis pas sur de bien comprendre la situation non plus en ce qui concerne ce qui est demandé pour la gestion des locales: chaque fois que j'expérimente autour de cela, je découvre que le comportement n'est pas celui auquel je m'attends. Et le sujet ne m'intéresse pas assez pour que je cherche à vérifier si c'est des bugs dans les systèmes ou une mauvaise compréhension de ma part.J'ai tenté de résumer nos discussions en une nouvelle question pour la FAQ:
Vos critiques sont les bienvenuesQuelle est la différence entre les type char et wchar_t ?
Le C++ possède deux types de caractères : le classique type char, dont la taille est définie comme faisant 1 byte (sizeof( char ) = 1), et le type caractère long (wide char) wchar_t dont la taille et le type réel sont laissés à la libre appréciation de chaque compilateur (implementation defined). Ainsi, avec Visual C++ sous Windows, wchar_t fait 2 octets, alors qu'avec g++ sous GNU/Linux il en fait 4.
Le type char de 8 bits (car un byte ne fait pas toujours 8 bits) est aussi appelé ANSI char, pour le différencier du wide char wchar_t. Etant donné que la plupart des machines modernes définissent la taille d'un byte à 8 bits, il est courant de parler d'ANSI string pour les char*, et de wide string pour les wchar_t* dans la terminologie purement C++. Comme les wide string ont généralement vocation à stocker des chaînes Unicode, on désigne aussi courament les wchar_t* par chaînes Unicode, bien que le standard n'ai pas cette notion.
Le C++ ne précise rien quant au système de codage de caractères (charset) associé à ces différents types de chaînes de caractères. En général, le type char sert à manipuler des caractères ASCII et le type wchar_t des caractères Unicode (dont le charset dépend de votre système / compilateur : UTF-16 sur 2 octets, UTF-32 sur 4...). Mais rien n'est définit par la norme. Celle-ci stipule simplement que char et wchar_t servent à stocker des caractères. Libre à vous de choisir le système d'encodage de ces derniers.
En général, votre programme va associer au type char le charset utilisé par la plateforme cible. Sur un ancien système IBM, char servira à manipuler des caractères EBCDIC. Sous Windows, il servira généralement à manipuler des caractères ASCII étendus (spécifiques à la langue en cours d'utilisation) mais aussi éventuellement des caractères OEM hérités de MS-DOS (typiquement pour afficher correctdement les accents dans la console).
Il y a plusieurs définitions, comme je l'ai dit.
"l'espace pour contenir un caractère" est la définition du C/C++.
La définition "originale", c'est l'espace adressable le plus petit. Il y a des système où la notion même de caractère n'a aucun intérêt.
Comme promis, voici ce que je crois savoir sur le sujet. Commençons par des notions indépendantes du langage utilisé.
Un caractère c'est une abstraction. La lettre A par exemple, ou le chiffre 5 ou le symbole +. Où ça devient plus intéressant, c'est de savoir si des choses comme les deux sigmas minuscules du grec (celui pour la dernière lettre ou une autre position) sont des caractères différents ou non. En gros, ça va être le charset utilisé qui va définir le niveau d'abstraction.
Un glyphe c'est la représentation dessinée du caractère. Un ensemble de glyphes, c'est une fonte.
Un code, c'est un nombre représentant un caractère.
Un coded character set (abbrévié en codeset ou en charset, on utilise aussi parfois codepage) c'est une table de correspondance entre des codes et des caractères. Normalement charque caractère a au plus un code. Les codesets les plus connus sont ASCII (aussi appelé ISO646-US, codeset sur 7 bits), EBCDIC (en fait une famille de codeset sur 8 bits avec des variantes nationales un peu les différentes variantes d'ISO-646 ou d'ISO-8859, utilisée principalement par les mainframes d'IBM), ISO-8859-1 (alias latin-1, extension de l'ASCII sur 8 bits longtemps le codeset normalisé le plus adéquat pour le français bien qu'il lui manque 3 caractères: œ, Œ et Ÿ), ISO-8859-15 (alias latin-0, alias latin-9, extension de l'ASCII sur 8 bits, adéquat pour le français, comporte aussi l'euro, fort semblable à ISO-8859-1), CP1252 (alias ms-ansi, windows-1252, extension de latin-1 récupérant des caractères de contrôle pour d'autres usages), Unicode (extension de l'ASCII sur a peu près 21 bits, se veut universel).
Un encodage c'est une manière de décoder une suite de bytes en une séquence de caractères (ou inversément d'encoder une séquence de caractères en une suite de bytes). Certains encodages peuvent représenter des caractères de plusieurs codesets différents. Soit ils présentent alors systématiquement l'information du codeset utilisé avec le caractère, soit ils utilisent un état indiquant quel codeset est en cours jusqu'au changement d'état différent. La différence entre encodage et codeset est particulièrement sensible pour unicode qui définit une série d'encodages pour son codeset (appelés UTF).
Un byte c'est donc l'unité élémentaire utilisée par un encodage.
Passons maintenant au C++. Le type char est utilisé pour représenter des bytes au sens ci-dessus. Le C++ impose en plus comme contrainte qu'un byte fasse au moins 8 bits et qu'il soit la plus petite unité adressable. Si on a une machine adressable par mot (ça devient très rare), on peut soit prendre pour byte un mot complet, soit utiliser une sous-division du mot avec des pointeurs qui contiennent une information sur la sous-division à utiliser. Si on a une machine adressable par bit (je n'en connais qu'une qui ait eu une vocation d'usage générale), on ne pourra pas profiter de la chose en C++.
En C++, le codeset et l'encodage à utiliser pour interpréter la valeur d'un byte comme caractère fait partie de la "locale''. Je ne rentrerai pas dans les détails sur les locales. Il y a quelques contraintes: il faut que tous les caractères du jeu de base (en gros, ceux qui servent dans la syntaxe) soit représentable par un seul byte et le même dans tous les encodages supportés et que dans tous les encodage ce byte représente toujours le caractère du jeu de base quel que soit le contexte.
Le type wchar_t est utilisé pour représenter des codes. Il faut qu'il soit assez grand pour contenir tous les codes du charset en ayant le plus. Il faut à nouveau que les caractères du jeu de base soient représentés par le même code dans tous les charsets.
Je n'ai pas vu ce point dans la norme (juste 7 bits, voir post dans l'autre thread). Est-ce par référence implicite au C, ou bien ai-je loupé quelque chose ?
J'ai pas cherché plus loin que 5.2.4.2.1 de ISO 9899-1990 qui dit que CHAR_BIT vaut au moins 8.Je n'ai pas vu ce point dans la norme (juste 7 bits, voir post dans l'autre thread). Est-ce par référence implicite au C, ou bien ai-je loupé quelque chose ?
D'accord, c'est donc la norme C. Je trouve dommage la façon dont on redéfinisse ce qu'est un char dans la norme C++.
J'aurais accepté un truc genre : C'est comme en C.
J'aurais accepté un truc genre : Voilà comment c'est, rien d'implicite.
J'aurais accepté un truc genre : C'est comme ça, et de plus, sur tel et tel point, où vous vous référez à la norme C
J'aurais accepté un truc genre : C'est comme la norme C, mais on rajoute X et Y
Par contre, là, la norme C n'est pas du tout référencée (ou dans une note, donc non normative, pour les int), mais elle a un impact quand même, ce que je trouve moyen.
J'ai vu une issue ouverte sur le sujet en octobre 1004 (483).
C'est à peut près cela: CHAR_BIT est dans limits.h et pour limits.h la norme C++ renvoie explicitement à la norme C. Mais ce n'est pas pour autant que le jeu de piste m'amuse...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager