Discussion :

[belam]

Salut à tous

Que je n'ai connu ce forum plus tôt. Voici quelques un de mes soucis du moment.

Y a-t-il un moyen de convertir une variable wchar_t en une variable char et réciproquement ?

Que signifie la notation _T() dans _T("Toto s'amuse") par exemple. Et si ystr est déclaré comme suit :

char ystr[16]

_T(ystr) a-t-il un sens ?

Merci d'avance

belam

A++

[belam]

Salut à tous

Hier j'ai envoyé un post qui avait le même intitulé que celui-ci mais je ne le vois pas.

Je re-pose ma préoccupation du moment.

1°) Y a-t-il moyen de transformer une variable de type wchar_t en (une autre) variable de type char et réciproquement tout en restant dans la plage de validité commune à ces 2 type de variable qui est, si je ne m'abuse, comprise entre -127 et 128.

2°) Que signifient les notations _T("toto est sage") et L"toto est sage".

3°) Si j'ai les deux lignes de code

char varstr[40];
strcpy(varstr, "toto est méchant");

l'expression

_T(varstr) a-t-elle un sens ?

Apparemment mon post d'hier est bien passé, mais je ne le vois pas dans le forum.


Merci


A++


belam

[Médinoc]

Bonjour,

1. Je pense que la plage de validité commune est plutôt 0 à 127. Quand les char sont encodés en ISO-8859-1 (ce qui n'est pas le cas sous Windows, qui utilise du Windows-1252 à la place), on peut caster le char en unsigned char et copier les valeurs 0 à 255. Mais sinon, il vaut mieux utiliser les fonctions de conversion prévues à cet effet.
2. L"toto est sage" signifie qu'on déclare une chaîne de wchar_t au lieu d'une chaîne de char. _T() est une macro qui signifie L ou rien du tout, selon des defines qui influent aussi le typedef de TCHAR et _TCHAR sous Windows: Quand TCHAR est un typedef sur wchar_t, _T() signifie L.
3. Non, _T() n'a de sens que sur les chaînes littérales. Tout comme L.

[belam]

Salut à tous

Medinoc, merci pour ta réponse.

Tu parles de "fonctions de conversion prévues à cet effet", lesquelles sont-ce ?

Merci d'avance.

A++

belam

[Médinoc]

De base, sous Windows, tu as WideCharToMultiByte() et MultiByteToWideChar(), ainsi, sous un Visual récent et non-payant (il faut la bibliothèque ATL), des classes de C++ conversion bien pratiques.

Sinon, il y a peut-être un truc plus ou moins standard, au niveau de mbstowcs() ou wcstombs(), mais j'ai tendance à préférer les premières, notamment au niveau de la gestion du buffer.

[belam]

Salut à tous

Encore merci Medinoc

A++

belam

[nicolas.sitbon]

Sinon, il y a peut-être un truc plus ou moins standard, au niveau de mbstowcs() ou wcstombs(),

Leur préféré les fonctions équivalentes mais réentrantes: mbsrtowcs() wcsrtombs(). Le 'r' supplémentaire signifie "restartable".
Cordialement.

[Médinoc]

Minute, je ne savais même pas que ces fonctions pouvaient avoir à sauvegarder un état!
Et je ne vois toujours pas quel genre d'état elles peuvent avoir à sauvegarder, d'ailleurs.

[Mac LAK]

C'est par rapport aux gestions d'erreur, quand tu leur passe NULL pour récupérer la taille nécessaire à la conversion et/ou le caractère en erreur si je me souviens bien.
De toutes façons, elles sont marquées deprecated : la "bonne" fonction à utiliser est mbstowcs_s.

De façon générale, il faut prendre systématiquement la fonction CRT avec l'extension "_s" (secured) dès que possible, vu qu'en C le remplacement automatique par template C++ n'est pas possible : il faut donc bien choisir sa fonction dès le départ, y compris en C++ (même si ce n'est pas strictement nécessaire avec ce langage), afin de prendre les bonnes habitudes lorsque l'on fait du C "pur" et non pas du C/C++.

[Médinoc]

Bien sûr, ça a l'horrible inconvénient d'être totalement non-standard, et par conséquent de ne pas marcher sous MinGW.

Résultat, quitte à utiliser des fonctions spécifiques à Windows, autant utiliser directement celles de l'API: WideCharToMultiByte() et MultiByteToWideChar()...

[Mac LAK]

Bien sûr, ça a l'horrible inconvénient d'être totalement non-standard, et par conséquent de ne pas marcher sous MinGW.

D'un autre côté, des fonctions de ce genre ("secured") sont faciles à implémenter, y compris sous forme de macros / fonctions inline, et devraient exister depuis belle lurette sous GCC... J'aurais quand même tendance à préférer l'utilisation de ces fonctions et de créer, au besoin, un .H d'adaptation plutôt que de me verrouiller totalement avec l'API Win32.

Toutefois, c'est un raisonnement que je fais à titre de portabilité d'OS : si c'est du dev Windows exclusif, surtout si le choix du compilateur (voire du langage !!!) n'est pas fixé, alors j'utilise au contraire l'API Win32 au maximum.

Mais que ce soit la fonction CRT secured ou celle de l'API Win32 (correctement encadrée bien sûr), les deux sont fiables : c'est plus un choix philosophique qu'autre chose ensuite.

[nicolas.sitbon]

De toutes façons, elles sont marquées deprecated : la "bonne" fonction à utiliser est mbstowcs_s.

Elles ne sont pas marquées deprecated (en tout les cas par aucune norme, pas même C1X ou POSIX 2008), et la fonction que tu cites n'est pas portable.

[Mac LAK]

Elles ne sont pas marquées deprecated (en tout les cas par aucune norme, pas même C1X ou POSIX 2008), et la fonction que tu cites n'est pas portable.

Voir MSDN :

Converts a sequence of multibyte characters to a corresponding sequence of wide characters. These functions are deprecated because more secure versions are available; see mbstowcs_s, _mbstowcs_s_l.

Sous Windows/Visual, elles le sont.


Pour la portabilité, voir #13.

[nicolas.sitbon]

Voir MSDN : Sous Windows/Visual, elles le sont.

MSDN n'est pas une norme, ni le man de GCC d'ailleurs (pour les autres).

Pour la portabilité, voir #13.

Donc le dénominateur commun reste les fonctions standards C, après libre à chacun de wrapper ça comme il le veut.

[Médinoc]

Disons que ces fonctions sont unilatéralement dépréciées par Microsoft, et je hais cette attitude, parce qu'elles font l'apologie de fonctions non-standard au lieu de nous donner les fonctions standard C99 qui feraient très bien le travail si on les emploie correctement (je pense à snprintf() notamment)!

Donc le dénominateur commun reste les fonctions standards C, après libre à chacun de wrapper ça comme il le veut.

Ou d'utiliser une alternative supérieure au lieu de les wrapper (d'ailleurs, [Edit: sous Windows,] ce sont plutôt les fonctions "standard C" qui wrappent l'alternative supérieure).

Edit: P*****, 'faut tout dire explicitement, ici...

[nicolas.sitbon]

Ou d'utiliser une alternative supérieure au lieu de les wrapper (d'ailleurs, ce sont plutôt les fonctions "standard C" qui wrappent l'alternative supérieure).

Sur un système POSIX, j'en doute! pour du code portable, il faudra se baser sur ces fonctions C.

[Médinoc]

Sur un système POSIX, j'en doute! pour du code portable, il faudra se baser sur ces fonctions C.

Vu que les locales autre que "C" ne sont pas portables, bonne chance.

Je ne pense pas que des bibliothèques comme iconv utilisent mbstowcs(). À mon avis, elles contiennent plutôt leur propre exemplaire des pages de codes...

[nicolas.sitbon]

Vu que les locales autre que "C" ne sont pas portables, bonne chance.

tu en oublies une qui est portable, c'est la locale native du système (""), et c'est là que les choses sont intéressantes.

Je ne pense pas que des bibliothèques comme iconv utilisent mbstowcs(). À mon avis, elles contiennent plutôt leur propre exemplaire des pages de codes...

iconv() n'est pas comparable à mbsrtowcs(). C'est 2 utilisations différentes, iconv() ne traite que des multibyte strings, alors que les fonctions C cités amènent un type de plus haut niveau qu'est wchar_t, les chaines de caractères larges, il y a des choses que l'on ne peut pas faire avec des char de manière portables mais que l'on peut faire avec des wchar_t.

[Médinoc]

tu en oublies une qui est portable, c'est la locale native du système (""), et c'est là que les choses sont intéressantes.

Je ne la considère pas comme portable vu que ce n'est pas la même sur différentes plate-formes. Ce qui nous donne, avec une certaine ironie du sort:

• La seule locale autre que "C" dont le nom est portable change d'une plate-forme à l'autre
• Les seules locales autres que "C" qui ne changent pas n'ont pas de nom portable.

iconv() n'est pas comparable à mbsrtowcs(). C'est 2 utilisations différentes, iconv() ne traite que des multibyte strings, alors que les fonctions C cités amènent un type de plus haut niveau qu'est wchar_t, les chaines de caractères larges, il y a des choses que l'on ne peut pas faire avec des char de manière portables mais que l'on peut faire avec des wchar_t.

Enfin, on se comprend, non?

Je n'aime pas le fait que mbstowcs() ne permette pas d'obtenir une taille de buffer.
On se retrouve à réserver une taille avec autant de wchar_t qu'il y avait de char, en se reposant (sur les systèmes UTF-16) sur l'hypothèse (dont je n'ai toujours pas lu la moindre garantie officielle nulle part) qu'aucune page de code ne contient un caractère hors du BMP codé sur un seul char.

[nicolas.sitbon]

Je ne la considère pas comme portable vu que ce n'est pas la même sur différentes plate-formes.

On s'en fiche, on sait que c'est la locale native et on n'a pas besoin de la nommer explicitement, c'est donc générique et optimisé en fonction de la plateforme.

Enfin, on se comprend, non?

En général, on se comprend toujours.

Je n'aime pas le fait que mbstowcs() ne permette pas d'obtenir une taille de buffer.
On se retrouve à réserver une taille avec autant de wchar_t qu'il y avait de char, en se reposant (sur les systèmes UTF-16) sur l'hypothèse (dont je n'ai toujours pas lu la moindre garantie officielle nulle part) qu'aucune page de code ne contient un caractère hors du BMP codé sur un seul char.

Pourquoi? je ne comprends pas le problème avec cette fonction!