Comment faire la definition d'une chaine de caractere WCHAR?
6 réponses
giova
Bonjour.
Je dois utiliser gdiplus.dll
la fonction a utiliser est : Bitmap(WCHAR*,BOOL)
je suis debutant je n'ai jamais travaillé avec le type WCHAR, plutot habitué
aux string . comment manipule t'on ce type? que faut il inclure pour pouvoir
l'utiliser?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Arnaud Debaene
giova wrote:
Bonjour.
Je dois utiliser gdiplus.dll
la fonction a utiliser est : Bitmap(WCHAR*,BOOL)
je suis debutant je n'ai jamais travaillé avec le type WCHAR, plutot habitué aux string . comment manipule t'on ce type? WCHAR = une macro pour wchar_t, un caractère large (Unicode). Codé sur 16
bits sous Windows, pls sur cetaines plates-formes.
que faut il inclure pour pouvoir l'utiliser? rien du tout, wchar_t est un type primitif. Utilises std::wstring (#include
<string>) pour te simplifier la gestion de ces chaînes. et std::wstring::c_str() pour obtenir le wchar_t correspondant à la chaine.
Arnaud
giova wrote:
Bonjour.
Je dois utiliser gdiplus.dll
la fonction a utiliser est : Bitmap(WCHAR*,BOOL)
je suis debutant je n'ai jamais travaillé avec le type WCHAR, plutot
habitué aux string . comment manipule t'on ce type?
WCHAR = une macro pour wchar_t, un caractère large (Unicode). Codé sur 16
bits sous Windows, pls sur cetaines plates-formes.
que faut il
inclure pour pouvoir l'utiliser?
rien du tout, wchar_t est un type primitif. Utilises std::wstring (#include
<string>) pour te simplifier la gestion de ces chaînes. et
std::wstring::c_str() pour obtenir le wchar_t correspondant à la chaine.
je suis debutant je n'ai jamais travaillé avec le type WCHAR, plutot habitué aux string . comment manipule t'on ce type? WCHAR = une macro pour wchar_t, un caractère large (Unicode). Codé sur 16
bits sous Windows, pls sur cetaines plates-formes.
que faut il inclure pour pouvoir l'utiliser? rien du tout, wchar_t est un type primitif. Utilises std::wstring (#include
<string>) pour te simplifier la gestion de ces chaînes. et std::wstring::c_str() pour obtenir le wchar_t correspondant à la chaine.
Arnaud
Fabien LE LEZ
On Tue, 6 Apr 2004 23:54:41 +0200, "Arnaud Debaene" wrote:
que faut il inclure pour pouvoir l'utiliser? rien du tout, wchar_t est un type primitif. Utilises std::wstring (#include
<string>) pour te simplifier la gestion de ces chaînes. et std::wstring::c_str() pour obtenir le wchar_t correspondant à la chaine.
c_str() renvoie un "wchar_t const*", non convertible en un "wchar_t" a priori.
De deux choses l'une : - soit la fonction ne modifie pas la chaîne, et tu peux utiliser const_cast<> avec force commentaires - soit la fonction modifie effectivement la chaîne, auquel cas tu dois connaître à l'avance la taille maximale de la chaîne. Et std::vector<wchar_t> me paraît le conteneur le plus approprié.
Exemple [non portable] (avec char, mais le principe est le même avec wchar_t) :
std::vector <char> buf (MAXDIR); // MAXDIR est la limite telle que définie par mon compilo if (getcurdir (drive, &(buf[0])) != 0) { Panique ("Y'a un blème !"); } else { std::string nom_repertoire (buf.begin()); ... }
que faut il
inclure pour pouvoir l'utiliser?
rien du tout, wchar_t est un type primitif. Utilises std::wstring (#include
<string>) pour te simplifier la gestion de ces chaînes. et
std::wstring::c_str() pour obtenir le wchar_t correspondant à la chaine.
c_str() renvoie un "wchar_t const*", non convertible en un "wchar_t" a
priori.
De deux choses l'une :
- soit la fonction ne modifie pas la chaîne, et tu peux utiliser
const_cast<> avec force commentaires
- soit la fonction modifie effectivement la chaîne, auquel cas
tu dois connaître à l'avance la taille maximale de la chaîne. Et
std::vector<wchar_t> me paraît le conteneur le plus approprié.
Exemple [non portable] (avec char, mais le principe est le même avec
wchar_t) :
std::vector <char> buf (MAXDIR); // MAXDIR est la limite telle
que définie par mon compilo
if (getcurdir (drive, &(buf[0])) != 0)
{ Panique ("Y'a un blème !");
}
else
{
std::string nom_repertoire (buf.begin());
...
}
On Tue, 6 Apr 2004 23:54:41 +0200, "Arnaud Debaene" wrote:
que faut il inclure pour pouvoir l'utiliser? rien du tout, wchar_t est un type primitif. Utilises std::wstring (#include
<string>) pour te simplifier la gestion de ces chaînes. et std::wstring::c_str() pour obtenir le wchar_t correspondant à la chaine.
c_str() renvoie un "wchar_t const*", non convertible en un "wchar_t" a priori.
De deux choses l'une : - soit la fonction ne modifie pas la chaîne, et tu peux utiliser const_cast<> avec force commentaires - soit la fonction modifie effectivement la chaîne, auquel cas tu dois connaître à l'avance la taille maximale de la chaîne. Et std::vector<wchar_t> me paraît le conteneur le plus approprié.
Exemple [non portable] (avec char, mais le principe est le même avec wchar_t) :
std::vector <char> buf (MAXDIR); // MAXDIR est la limite telle que définie par mon compilo if (getcurdir (drive, &(buf[0])) != 0) { Panique ("Y'a un blème !"); } else { std::string nom_repertoire (buf.begin()); ... }
-- ;-)
giova
J'ai rencontre encore beaucoup de mal manipuler ce type.
mon constructeur : Bitmap(WCHAR*,BOOL)
attend un WCHAR* qui en fait represente le nom du fichier a ouvrir. je souhaite faire une classe avec un attribut de ce type, voir de type string avec une fonction WCHAR* GetString(void)
Lorsque j'appelle le constructeurBitmap(WCHAR*,BOOL) le compilateur me jete me disant que le premier parametre de type std::wstring ne peut etre converti en WCHAR* j'avoue ne pas trop m'y retrouver dans les doc msdn pour retrouver toutes les fonctions de wchar, et ainsi trouver comment convertir un wstring en WCHAR*
"Fabien LE LEZ" a écrit dans le message de news:
On Tue, 6 Apr 2004 23:54:41 +0200, "Arnaud Debaene" wrote:
que faut il inclure pour pouvoir l'utiliser? rien du tout, wchar_t est un type primitif. Utilises std::wstring
(#include
<string>) pour te simplifier la gestion de ces chaînes. et std::wstring::c_str() pour obtenir le wchar_t correspondant à la chaine.
c_str() renvoie un "wchar_t const*", non convertible en un "wchar_t" a priori.
De deux choses l'une : - soit la fonction ne modifie pas la chaîne, et tu peux utiliser const_cast<> avec force commentaires - soit la fonction modifie effectivement la chaîne, auquel cas tu dois connaître à l'avance la taille maximale de la chaîne. Et std::vector<wchar_t> me paraît le conteneur le plus approprié.
Exemple [non portable] (avec char, mais le principe est le même avec wchar_t) :
std::vector <char> buf (MAXDIR); // MAXDIR est la limite telle que définie par mon compilo if (getcurdir (drive, &(buf[0])) != 0) { Panique ("Y'a un blème !"); } else { std::string nom_repertoire (buf.begin()); ... }
-- ;-)
J'ai rencontre encore beaucoup de mal manipuler ce type.
mon constructeur : Bitmap(WCHAR*,BOOL)
attend un WCHAR* qui en fait represente le nom du fichier a ouvrir. je
souhaite faire une classe avec un attribut de ce type, voir de type string
avec une fonction WCHAR* GetString(void)
Lorsque j'appelle le constructeurBitmap(WCHAR*,BOOL) le compilateur me jete
me disant que le premier parametre de type std::wstring ne peut etre
converti en WCHAR*
j'avoue ne pas trop m'y retrouver dans les doc msdn pour retrouver toutes
les fonctions de wchar, et ainsi trouver comment convertir un wstring en
WCHAR*
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de
news:kqg6705k7kvr1pbnq76pv7b0u8s4sdii8u@4ax.com...
que faut il
inclure pour pouvoir l'utiliser?
rien du tout, wchar_t est un type primitif. Utilises std::wstring
(#include
<string>) pour te simplifier la gestion de ces chaînes. et
std::wstring::c_str() pour obtenir le wchar_t correspondant à la chaine.
c_str() renvoie un "wchar_t const*", non convertible en un "wchar_t" a
priori.
De deux choses l'une :
- soit la fonction ne modifie pas la chaîne, et tu peux utiliser
const_cast<> avec force commentaires
- soit la fonction modifie effectivement la chaîne, auquel cas
tu dois connaître à l'avance la taille maximale de la chaîne. Et
std::vector<wchar_t> me paraît le conteneur le plus approprié.
Exemple [non portable] (avec char, mais le principe est le même avec
wchar_t) :
std::vector <char> buf (MAXDIR); // MAXDIR est la limite telle
que définie par mon compilo
if (getcurdir (drive, &(buf[0])) != 0)
{ Panique ("Y'a un blème !");
}
else
{
std::string nom_repertoire (buf.begin());
...
}
J'ai rencontre encore beaucoup de mal manipuler ce type.
mon constructeur : Bitmap(WCHAR*,BOOL)
attend un WCHAR* qui en fait represente le nom du fichier a ouvrir. je souhaite faire une classe avec un attribut de ce type, voir de type string avec une fonction WCHAR* GetString(void)
Lorsque j'appelle le constructeurBitmap(WCHAR*,BOOL) le compilateur me jete me disant que le premier parametre de type std::wstring ne peut etre converti en WCHAR* j'avoue ne pas trop m'y retrouver dans les doc msdn pour retrouver toutes les fonctions de wchar, et ainsi trouver comment convertir un wstring en WCHAR*
"Fabien LE LEZ" a écrit dans le message de news:
On Tue, 6 Apr 2004 23:54:41 +0200, "Arnaud Debaene" wrote:
que faut il inclure pour pouvoir l'utiliser? rien du tout, wchar_t est un type primitif. Utilises std::wstring
(#include
<string>) pour te simplifier la gestion de ces chaînes. et std::wstring::c_str() pour obtenir le wchar_t correspondant à la chaine.
c_str() renvoie un "wchar_t const*", non convertible en un "wchar_t" a priori.
De deux choses l'une : - soit la fonction ne modifie pas la chaîne, et tu peux utiliser const_cast<> avec force commentaires - soit la fonction modifie effectivement la chaîne, auquel cas tu dois connaître à l'avance la taille maximale de la chaîne. Et std::vector<wchar_t> me paraît le conteneur le plus approprié.
Exemple [non portable] (avec char, mais le principe est le même avec wchar_t) :
std::vector <char> buf (MAXDIR); // MAXDIR est la limite telle que définie par mon compilo if (getcurdir (drive, &(buf[0])) != 0) { Panique ("Y'a un blème !"); } else { std::string nom_repertoire (buf.begin()); ... }
-- ;-)
Martinez Jerome
giova wrote:
Lorsque j'appelle le constructeurBitmap(WCHAR*,BOOL) le compilateur me jete me disant que le premier parametre de type std::wstring ne peut etre converti en WCHAR* j'avoue ne pas trop m'y retrouver dans les doc msdn pour retrouver toutes les fonctions de wchar, et ainsi trouver comment convertir un wstring en WCHAR*
comme dit précédement : wstring::c_str() pour avoir la version "a la C" qu'aime Windows (l'API est en C, pas C++). Il te donnera le const wchar* que tu cherches.
wchar_t n'a pas de fonction, c'est un type de base comme char, int etc...
wchar_t est le pendant UNICODE de char, a manipuler comme char. Tu disposes dans l'API windows d'outils de conversion char (que tu recuperes de certaines fonctions windows) en wchar_t. Me rappelle plus le nom, voir le newsgroup adapté.
Remarque : pour ecrire dans le code un nom de fichier, utiliser : std::string Ansi="C:a.txt"; //version ansi, habituelle std::wstring Unicode=L"C:a.txt"; //version unicode
giova wrote:
Lorsque j'appelle le constructeurBitmap(WCHAR*,BOOL) le compilateur me jete
me disant que le premier parametre de type std::wstring ne peut etre
converti en WCHAR*
j'avoue ne pas trop m'y retrouver dans les doc msdn pour retrouver toutes
les fonctions de wchar, et ainsi trouver comment convertir un wstring en
WCHAR*
comme dit précédement :
wstring::c_str() pour avoir la version "a la C" qu'aime Windows (l'API
est en C, pas C++).
Il te donnera le const wchar* que tu cherches.
wchar_t n'a pas de fonction, c'est un type de base comme char, int etc...
wchar_t est le pendant UNICODE de char, a manipuler comme char.
Tu disposes dans l'API windows d'outils de conversion char (que tu
recuperes de certaines fonctions windows) en wchar_t. Me rappelle plus
le nom, voir le newsgroup adapté.
Remarque : pour ecrire dans le code un nom de fichier, utiliser :
std::string Ansi="C:\a.txt"; //version ansi, habituelle
std::wstring Unicode=L"C:\a.txt"; //version unicode
Lorsque j'appelle le constructeurBitmap(WCHAR*,BOOL) le compilateur me jete me disant que le premier parametre de type std::wstring ne peut etre converti en WCHAR* j'avoue ne pas trop m'y retrouver dans les doc msdn pour retrouver toutes les fonctions de wchar, et ainsi trouver comment convertir un wstring en WCHAR*
comme dit précédement : wstring::c_str() pour avoir la version "a la C" qu'aime Windows (l'API est en C, pas C++). Il te donnera le const wchar* que tu cherches.
wchar_t n'a pas de fonction, c'est un type de base comme char, int etc...
wchar_t est le pendant UNICODE de char, a manipuler comme char. Tu disposes dans l'API windows d'outils de conversion char (que tu recuperes de certaines fonctions windows) en wchar_t. Me rappelle plus le nom, voir le newsgroup adapté.
Remarque : pour ecrire dans le code un nom de fichier, utiliser : std::string Ansi="C:a.txt"; //version ansi, habituelle std::wstring Unicode=L"C:a.txt"; //version unicode
Arnaud Meurgues
Martinez Jerome wrote:
wchar_t est le pendant UNICODE de char, a manipuler comme char.
Je ne suis pas sûr qu'on puisse considérer que wchar_t soit unicode. D'abord parce qu'unicode, ce n'est pas une représentation, c'est un mapping entre un nombre et un caractère. On peut très bien représenter de l'unicode dans des char si l'on utilise l'UTF8. Ensuite, parce que la norme n'impose rien sur le format de wchar_t. On pourrait espérer, afin de supporte l'UTF32 (qui pourrait être considéré comme la représentation la plus naturelle d'unicode) que soit demandé à wchar_t d'avoir au moins 32 bits. Mais ce n'est pas le cas. Si je ne me trompe pas, wchar_t peut même être un typedef de char.
-- Arnaud (Supprimez les geneurs pour me répondre)
Martinez Jerome wrote:
wchar_t est le pendant UNICODE de char, a manipuler comme char.
Je ne suis pas sûr qu'on puisse considérer que wchar_t soit unicode.
D'abord parce qu'unicode, ce n'est pas une représentation, c'est un
mapping entre un nombre et un caractère. On peut très bien représenter
de l'unicode dans des char si l'on utilise l'UTF8.
Ensuite, parce que la norme n'impose rien sur le format de wchar_t.
On pourrait espérer, afin de supporte l'UTF32 (qui pourrait être
considéré comme la représentation la plus naturelle d'unicode) que soit
demandé à wchar_t d'avoir au moins 32 bits. Mais ce n'est pas le cas. Si
je ne me trompe pas, wchar_t peut même être un typedef de char.
--
Arnaud
(Supprimez les geneurs pour me répondre)
wchar_t est le pendant UNICODE de char, a manipuler comme char.
Je ne suis pas sûr qu'on puisse considérer que wchar_t soit unicode. D'abord parce qu'unicode, ce n'est pas une représentation, c'est un mapping entre un nombre et un caractère. On peut très bien représenter de l'unicode dans des char si l'on utilise l'UTF8. Ensuite, parce que la norme n'impose rien sur le format de wchar_t. On pourrait espérer, afin de supporte l'UTF32 (qui pourrait être considéré comme la représentation la plus naturelle d'unicode) que soit demandé à wchar_t d'avoir au moins 32 bits. Mais ce n'est pas le cas. Si je ne me trompe pas, wchar_t peut même être un typedef de char.
-- Arnaud (Supprimez les geneurs pour me répondre)
kanze
Arnaud Meurgues wrote in message news:<407559f8$0$22879$...
Martinez Jerome wrote:
wchar_t est le pendant UNICODE de char, a manipuler comme char.
Je ne suis pas sûr qu'on puisse considérer que wchar_t soit unicode.
En général, certainement pas. La norme C++ n'en exige rien.
Dans la pratique, je crois qu'aujourd'hui, si une implémentation supporte bien un type de caractère plus large (c-à-d un wchar_t qui est différent de char), et c'est le cas des implémentations courantes, on est en droit à s'attendre à ce que son encodage soit basé sur l'Unicode. Qualité de l'implémentation exige.
D'abord parce qu'unicode, ce n'est pas une représentation, c'est un mapping entre un nombre et un caractère. On peut très bien représenter de l'unicode dans des char si l'on utilise l'UTF8.
Ou UTF-16:-).
Ensuite, parce que la norme n'impose rien sur le format de wchar_t. On pourrait espérer, afin de supporte l'UTF32 (qui pourrait être considéré comme la représentation la plus naturelle d'unicode) que soit demandé à wchar_t d'avoir au moins 32 bits.
Si on commençait de rien, et qu'on n'avait aucun contraint de l'existant, c'est sûr que la solution « idéale » serait UCS-4 en interne, et UTF-8 en externe. L'intention du comité, c'est bien qu'un wchar_t contient un caractère complet, sans qu'il soit nécessaire à se retourner à un jeu de « représentation » (avec des encodages qui dépend de l'état ou des caractères composés). (Note qu'en interne, on peut avoir réelement un « jeu de caractère », avec des valeurs entières qui représentent des caractères, indépendamment de la « représentation » de ces valeurs.) Mais c'est une luxe que n'a que ceux qui sont venu tardivement à l'internationalisation. Pendant longtemps, Unicode prétendait que 16 bits suffiraient.
En attendant, il y a des fournisseurs qui se sont fixé sur 16 bits, selon les anciennes normes Unicode, et qui sont coincés par des problèmes de compatibilité. Ils ont le choix entre se restreindre à UCS-2 (un sous-ensemble de Unicode) ou de passer à UTF-16 (un encodage qui utilise des caractères composés). Dans l'ensemble, c'est la deuxième solution qui a été adoptée. (J'avoue ne pas trop comprendre pourquoi. Du moment que j'accepte de traiter des caractères composés, pourquoi pas passer carrément à UTF-8 ?)
Mais ce n'est pas le cas. Si je ne me trompe pas, wchar_t peut même être un typedef de char.
Selon la norme, oui. Sur les machines généraliste courantes, c'est prèsque toujours soit 16 bits (UTF-16, chez Microsoft et IBM), soit 32 bits (UCS-4, chez des Unix, sauf AIX, et chez Linux).
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Arnaud Meurgues <arnaud@meurgues.non.fr.invalid> wrote in message
news:<407559f8$0$22879$626a14ce@news.free.fr>...
Martinez Jerome wrote:
wchar_t est le pendant UNICODE de char, a manipuler comme char.
Je ne suis pas sûr qu'on puisse considérer que wchar_t soit unicode.
En général, certainement pas. La norme C++ n'en exige rien.
Dans la pratique, je crois qu'aujourd'hui, si une implémentation
supporte bien un type de caractère plus large (c-à-d un wchar_t qui est
différent de char), et c'est le cas des implémentations courantes, on
est en droit à s'attendre à ce que son encodage soit basé sur l'Unicode.
Qualité de l'implémentation exige.
D'abord parce qu'unicode, ce n'est pas une représentation, c'est un
mapping entre un nombre et un caractère. On peut très bien représenter
de l'unicode dans des char si l'on utilise l'UTF8.
Ou UTF-16:-).
Ensuite, parce que la norme n'impose rien sur le format de wchar_t.
On pourrait espérer, afin de supporte l'UTF32 (qui pourrait être
considéré comme la représentation la plus naturelle d'unicode) que
soit demandé à wchar_t d'avoir au moins 32 bits.
Si on commençait de rien, et qu'on n'avait aucun contraint de
l'existant, c'est sûr que la solution « idéale » serait UCS-4 en
interne, et UTF-8 en externe. L'intention du comité, c'est bien qu'un
wchar_t contient un caractère complet, sans qu'il soit nécessaire à se
retourner à un jeu de « représentation » (avec des encodages qui dépend
de l'état ou des caractères composés). (Note qu'en interne, on peut
avoir réelement un « jeu de caractère », avec des valeurs entières qui
représentent des caractères, indépendamment de la « représentation » de
ces valeurs.) Mais c'est une luxe que n'a que ceux qui sont venu
tardivement à l'internationalisation. Pendant longtemps, Unicode
prétendait que 16 bits suffiraient.
En attendant, il y a des fournisseurs qui se sont fixé sur 16 bits,
selon les anciennes normes Unicode, et qui sont coincés par des
problèmes de compatibilité. Ils ont le choix entre se restreindre à
UCS-2 (un sous-ensemble de Unicode) ou de passer à UTF-16 (un encodage
qui utilise des caractères composés). Dans l'ensemble, c'est la deuxième
solution qui a été adoptée. (J'avoue ne pas trop comprendre pourquoi. Du
moment que j'accepte de traiter des caractères composés, pourquoi pas
passer carrément à UTF-8 ?)
Mais ce n'est pas le cas. Si je ne me trompe pas, wchar_t peut même
être un typedef de char.
Selon la norme, oui. Sur les machines généraliste courantes, c'est
prèsque toujours soit 16 bits (UTF-16, chez Microsoft et IBM), soit
32 bits (UCS-4, chez des Unix, sauf AIX, et chez Linux).
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Arnaud Meurgues wrote in message news:<407559f8$0$22879$...
Martinez Jerome wrote:
wchar_t est le pendant UNICODE de char, a manipuler comme char.
Je ne suis pas sûr qu'on puisse considérer que wchar_t soit unicode.
En général, certainement pas. La norme C++ n'en exige rien.
Dans la pratique, je crois qu'aujourd'hui, si une implémentation supporte bien un type de caractère plus large (c-à-d un wchar_t qui est différent de char), et c'est le cas des implémentations courantes, on est en droit à s'attendre à ce que son encodage soit basé sur l'Unicode. Qualité de l'implémentation exige.
D'abord parce qu'unicode, ce n'est pas une représentation, c'est un mapping entre un nombre et un caractère. On peut très bien représenter de l'unicode dans des char si l'on utilise l'UTF8.
Ou UTF-16:-).
Ensuite, parce que la norme n'impose rien sur le format de wchar_t. On pourrait espérer, afin de supporte l'UTF32 (qui pourrait être considéré comme la représentation la plus naturelle d'unicode) que soit demandé à wchar_t d'avoir au moins 32 bits.
Si on commençait de rien, et qu'on n'avait aucun contraint de l'existant, c'est sûr que la solution « idéale » serait UCS-4 en interne, et UTF-8 en externe. L'intention du comité, c'est bien qu'un wchar_t contient un caractère complet, sans qu'il soit nécessaire à se retourner à un jeu de « représentation » (avec des encodages qui dépend de l'état ou des caractères composés). (Note qu'en interne, on peut avoir réelement un « jeu de caractère », avec des valeurs entières qui représentent des caractères, indépendamment de la « représentation » de ces valeurs.) Mais c'est une luxe que n'a que ceux qui sont venu tardivement à l'internationalisation. Pendant longtemps, Unicode prétendait que 16 bits suffiraient.
En attendant, il y a des fournisseurs qui se sont fixé sur 16 bits, selon les anciennes normes Unicode, et qui sont coincés par des problèmes de compatibilité. Ils ont le choix entre se restreindre à UCS-2 (un sous-ensemble de Unicode) ou de passer à UTF-16 (un encodage qui utilise des caractères composés). Dans l'ensemble, c'est la deuxième solution qui a été adoptée. (J'avoue ne pas trop comprendre pourquoi. Du moment que j'accepte de traiter des caractères composés, pourquoi pas passer carrément à UTF-8 ?)
Mais ce n'est pas le cas. Si je ne me trompe pas, wchar_t peut même être un typedef de char.
Selon la norme, oui. Sur les machines généraliste courantes, c'est prèsque toujours soit 16 bits (UTF-16, chez Microsoft et IBM), soit 32 bits (UCS-4, chez des Unix, sauf AIX, et chez Linux).
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
