Conversions Unicode Ascii

Version imprimable

09/02/2007, 03h07
Klaim

Conversions Unicode Ascii
Bonjour,

Apparemment le code que l'on retrouve là : Comment effectuer les conversions de texte ASCII <-> Unicode ? ne compile pas sous VC8 SP1.

L'erreur apparait dés la première ligne de chaque fonction, voici la première :
Code:

1 2 cannot convert parameter 1 from 'const std::wstring' to 'std::basic_string<_Elem,_Traits,_Ax>::_Has_debug_it'
A priori ça ressemble a un mauvais copier coller?

Par ailleurs, est-ce que ce code fonctionnera pour tous les charactères Unicodes (donc tous ceux possibles) ou est-ce qu'il faut changer la locale de manière a ce que ça corresponde? Où se trouvent les définitions des locales?

Merci de votre attention :)

Le code dans la FAQ

Code:

1
2
3
4
5
6
7
8
std::string narrow(const std::wstring& ws)
{
    std::string res(ws);
    std::locale loc("english");
    std::use_facet< std::ctype<wchar_t> >(loc).narrow(&ws[0], &ws[ws.length()], '?', &res[0]);
 
    return res;
}

a au moins trois erreurs :

1) std::string res(ws); n'est pas valide
2) &ws[ws.length()] n'est pas valide
3) &res[0] ne retourne pas forcement un pointeur vers les caractères de la chaine

Il faudrait le remplacer par quelque chose comme ça

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#include <string>
#include <locale>
#include <vector>
 
std::string narrow(const std::wstring& ws)
{
    std::vector<char> buffer(ws.size());
    std::locale loc("english");
    std::use_facet< std::ctype<wchar_t> >(loc).narrow(ws.data(), ws.data() + ws.size(), '?', &buffer[0]);
 
    return std::string(&buffer[0], buffer.size());
}
 
std::wstring widen(const std::string& s)
{
    std::vector<wchar_t> buffer(s.size());
    std::locale loc("english");
    std::use_facet< std::ctype<wchar_t> >(loc).widen(s.data(), s.data() + s.size(), &buffer[0]);
 
    return std::wstring(&buffer[0], buffer.size());
}

09/02/2007, 10h39
Laurent Gomila

On va corriger ça, merci ;)
09/02/2007, 11h12
Klaim

Merci pour la correction, je vais tester ça de suite.

En attendant je réitère mes questions :

Citation:

Par ailleurs, est-ce que ce code fonctionnera pour tous les charactères Unicodes (donc tous ceux possibles) ou est-ce qu'il faut changer la locale de manière a ce que ça corresponde? Où se trouvent les définitions des locales?

Comme je m'en doutais, le code de la FAQ ne marche pas dans tous les cas.

Je l'ai proposé sur le forume de Ogre : http://www.ogre3d.org/phpBB2/viewtop...=230609#230609

Voici une variante avec test proposée dans le thread :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
 
#include "stdafx.h"
#include <string>
#include <locale>
#include <stdlib.h>
 
using namespace std;
 
wstring toWideString(const string &str)
{
   size_t size = mbstowcs(NULL, str.c_str(), 0) + 1;
   wchar_t *wmsg = new wchar_t[size];
   mbstowcs(wmsg, str.c_str(), size);
   wstring ret(wmsg);
   delete wmsg;
   return ret;
}
 
 
string toString(const wstring &wstr)
{
   size_t size = wcstombs(NULL, wstr.c_str(), 0) + 1;
   char *msg = new char[size];
   wcstombs(msg, wstr.c_str(), size);
   string ret(msg);
   delete msg;
   return ret;
}
 
int _tmain(int argc, _TCHAR* argv[])
{
   string hello("Hello World!");
   wstring hellow = toWideString(hello);
 
   wstring byew(L"Goodbye!");
   string bye = toString(byew);
   return 0;
}

Pourrais-je avoir votre avis là dessus ? Je capte pas tout au niveau du jonglage avec les locales pour l'instant...

16/06/2007, 11h42
superspag
Tiens ? Je n'avais même pas remarqué que mon code était dans la FAQ... :lol:
Il ne correspond cependant pas tout à fait à ce que j'avais proposé... Il faut remplacer :
Code:

1 2 std::string s(ws) ;
par
Code:

1 2 3 std::string s; s.resize(ws.length()) ;
et
Code:

1 2 std::string ws(s) ;
par
Code:

1 2 3 std::string ws ; ws.resize(s.length()) ;
Le but est simplement de construire une chaine du bon type et avec la bonne taille. Peut importe ce qu'il y a dedant ;)

Par contre, je ne vois pas en quoi l'utilisation de l'opérateur [] est une erreur... Quelqu'un peut m'eclairer ? Il y a peutetre une subtilité qui m'échape :aie:

Bizarre que ça ne fonctionne pas sous VC, c'est justement le seul compilo avec lequel ça avait fonctionné pour moi :mrgreen:
Sinon, voici un code qui a fonctionné pour un projet que j'ai testé sous VC (7.1?), Mingw et GCC:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 #include <string> #include <locale> std::string narrow(const std::wstring& ws) { std::string res(ws.length(),' '); std::locale loc("english"); std::use_facet< std::ctype<wchar_t> >(loc).narrow(&ws[0], &ws[ws.length()], '?', &res[0]); return res; } std::wstring widen(const std::string& s) { std::wstring res(s.length(),' '); std::locale loc("english"); std::use_facet< std::ctype<wchar_t> >(loc).widen(&s[0], &s[s.length()], &res[0]); return res; }
PS: sérieux, faudrait quand même tester un minimum avant de mettre des trucs dans la faq, ça ne compile même pas avec un compilo standard.

18/06/2007, 12h10
Sylvain Togni

Citation:

Envoyé par superspag

Par contre, je ne vois pas en quoi l'utilisation de l'opérateur [] est une erreur... Quelqu'un peut m'eclairer ? Il y a peutetre une subtilité qui m'échape :aie:

C'est l'utilisation de &res[0] qui est problématique car la norme ne garanti pas que les éléments d'une std::string sont contigus en mémoire (seul std::vector a cette garantie).
18/06/2007, 23h09
zais_ethael

Citation:

Envoyé par Sylvain Togni

C'est l'utilisation de &res[0] qui est problématique car la norme ne garanti pas que les éléments d'une std::string sont contigus en mémoire (seul std::vector a cette garantie).

Je ne vois pas comment ce serait possible d'implémenter un string sans cette garantie. La méthode c_str() renvoie un const char*, c'est obligatoirement une copie du char* utilisé en interne et pointe donc vers les mêmes charactères. Si ce n'était pas le cas il faudrait gérer le cycle de vie de ce nouveau buffer (et ça le standard ne serait pas d'accord).
19/06/2007, 07h15
Laurent Gomila

Citation:

Je ne vois pas comment ce serait possible d'implémenter un string sans cette garantie. La méthode c_str() renvoie un const char*, c'est obligatoirement une copie du char* utilisé en interne et pointe donc vers les mêmes charactères. Si ce n'était pas le cas il faudrait gérer le cycle de vie de ce nouveau buffer (et ça le standard ne serait pas d'accord).

Et pourtant si. Rien n'indique dans la norme que les caractères doivent être contigüs en mémoire, et c'est notamment pour cela que le pointeur renvoyé par c_str() n'est plus considéré comme valide après l'appel (la chaîne peut être un temporaire construit juste pour l'appel).
En pratique ce n'est jamais le cas, mais dans le standard c'est comme ça.
19/06/2007, 13h10
zais_ethael

Mais comment les données pointées par un const char* pourraient-elles être détruites après l'appel? C'est impossible, par contre je comprends très bien qu'il ne faille plus utiliser ce pointeur après l'appel, pour la simple raison que le string pourrait être détruit entre temps.
19/06/2007, 13h25
Jean-Marc.Bourguet

Citation:

Envoyé par Sylvain Togni

C'est l'utilisation de &res[0] qui est problématique car la norme ne garanti pas que les éléments d'une std::string sont contigus en mémoire (seul std::vector a cette garantie).

Ca le sera en C0X. Je doute qu'il y ait beaucoup d'implementations ou ce n'est pas le cas.
19/06/2007, 13h30
rikau2

La chaine de caractères n'est pas forcement détruite après l'appel, mais tout simplement aucun element (pointeur) ne permet d'acceder à la chaine.

La mémoire sera reécrite ultèrieurement aux besoins de l'OS. En effet le système de gestion de la mémoire est mis à jour par l'OS pour indiquer que cette espace mémoire est à nouveau disponible.
19/06/2007, 13h44
Jean-Marc.Bourguet

Citation:

Envoyé par zais_ethael

Je ne vois pas comment ce serait possible d'implémenter un string sans cette garantie. La méthode c_str() renvoie un const char*, c'est obligatoirement une copie du char* utilisé en interne et pointe donc vers les mêmes charactères. Si ce n'était pas le cas il faudrait gérer le cycle de vie de ce nouveau buffer (et ça le standard ne serait pas d'accord).

Le resultat de c_str() n'est pas necessairement ce qui est utilise en interne, il ne faut pas tenter de le modifier et tout appel a un membre non const (ou au destructeur) l'invalide.
19/06/2007, 13h46
Jean-Marc.Bourguet

Citation:

Envoyé par zais_ethael

Mais comment les données pointées par un const char* pourraient-elles être détruites après l'appel? C'est impossible, par contre je comprends très bien qu'il ne faille plus utiliser ce pointeur après l'appel, pour la simple raison que le string pourrait être détruit entre temps.

On peut utiliser le resultat de c_str() jusqu'a un appel a un membre non const ou au destructeur.
19/06/2007, 23h43
epsilon68

et ICU ?
21/06/2007, 15h08
zais_ethael

Citation:

Envoyé par rikau2

La chaine de caractères n'est pas forcement détruite après l'appel, mais tout simplement aucun element (pointeur) ne permet d'acceder à la chaine.

La mémoire sera reécrite ultèrieurement aux besoins de l'OS. En effet le système de gestion de la mémoire est mis à jour par l'OS pour indiquer que cette espace mémoire est à nouveau disponible.

Ca c'est ce qu'on appelle un garbage collector. Comme on est en C++, ça n'existe pas et le terme approprié est plutot fuite mémoire.
21/06/2007, 19h14
rikau2
Citation:

Envoyé par zais_ethael

Ca c'est ce qu'on appelle un garbage collector. Comme on est en C++, ça n'existe pas et le terme approprié est plutot fuite mémoire.

je parlais de l'appel simple a:
Code:

1 2 3 string str; mafonction(str.c_str());
Merci de m'expliquer dans ce cas comment libérer la mémoire,...... j'aimerai bien savoir
22/06/2007, 09h34
Médinoc

Il n'y a rien à libérer ici, car l'objet string est sur la pile et son destructeur sera automatiquement appelé.
Pour la fonction c_str(), la plupart des implémentations retournent directement le pointeur de la string, mais si une implémentation retourne un objet temporaire, lui aussi sera détruit automatiquement.
28/06/2007, 22h34
zais_ethael
Citation:
Envoyé par rikau2

je parlais de l'appel simple a:

Code:

1 2 3 string str; mafonction(str.c_str());

Merci de m'expliquer dans ce cas comment libérer la mémoire,...... j'aimerai bien savoir
Mais c'est exactement ce que je dis, c'est impossible! La seule solution est qu'on aie pas besoin de libérer la mémoire et que, de fait, le const char* qui soit retourné ne puisse en aucun cas être un objet temporaire.

Citation:

Envoyé par Médinoc

Pour la fonction c_str(), la plupart des implémentations retournent directement le pointeur de la string, mais si une implémentation retourne un objet temporaire, lui aussi sera détruit automatiquement.

Mais puisque je dis que c'est impossible, vous avez déja vu un const char* avec un destructeur vous?
29/06/2007, 07h22
Médinoc

Non, mais un objet avec un operator const char *, oui.
30/06/2007, 00h15
zais_ethael

Mais ce serait alors assez éloigné du standard... c'est à peu près la seule chose qu'il spécifie: l'interface des classes.
30/06/2007, 10h16
Médinoc

Bizarre, il me semblait avoir lu au contraire (posté par un des gourous C++ du forum) que c_str() pouvait tout-à-fait retourner un objet temporaire au lieu de retourner directement un char const* ...
30/06/2007, 18h10
Jean-Marc.Bourguet

Citation:

Envoyé par Médinoc

Bizarre, il me semblait avoir lu au contraire (posté par un des gourous C++ du forum) que c_str() pouvait tout-à-fait retourner un objet temporaire au lieu de retourner directement un char const* ...

Ca ne me dit rien -- et je ne vois rien de semblable après une courte exégèse. Tu peux retrouver une référence?
30/06/2007, 20h42
Médinoc

Non, je ne retrouve rien. Tant pis...
01/08/2007, 22h15
Klaim

Apparamment le code dans la FAQ est revenu en arrière et repose les même problèmes que ce que j'indiquais dans mon premier post...

Fuseau horaire GMT +2. Il est actuellement 23h18.