Discussion :

[camboui]

TCHAR est un #define sur char ou wchar_t.
Existe-t-il les m�mes #define pour cout et wcout, string et wstring, ostringstream et wostringstream, etc ?
Merci.

[koala01]

Salut,

En fait, string,istringstream, ostringstream wstring, wistringstream et wostringstrieam ne sont que des typedef de classes template, les uns sp�cialisant celles-ci avec des char, les autres les sp�cialisant avec des wchar.

cin et cout sont, quant � elles, des instances globales de variables, dont le type est, de mani�re g�n�rale, d�riv�e des m�me flux que les *stringstream.

Ce ne sont normalement pas de define, mais bel et bien des typedef

[Sylvain Togni]

Tu peux les d�finir toi m�me :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
#ifdef _UNICODE
typedef std::wstring tstring;
...
#else
typedef std::string tstring;
...
#endif

ou une autre fa�on de faire :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
typedef std::basic_string<TCHAR> tstring;
...

[camboui]

koala01, merci mais je crois que tu n'as pas compris ma question.

Sylvain, merci. J'aime bien l'autre fa�on de faire

Donc rien n'est pr�vu en C++ pour compiler un projet enti�rement en unicode ou en ascii. Ce n'est pr�vu que lorsqu'on fait du C avec l'api Windows et/ou la crt lib (avec les _tcscpy, _tcscmp, etc).

Voil� � quoi j'en suis r�duit, c'est pas trop �l�gant je trouve

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

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
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
#include <iostream>
#include <iomanip>
#include "tchar.h"
#include <string>
 
#ifndef _tstring
# ifdef _UNICODE
#  define _tstring wstring
#else
#  define _tstring string
# endif
#endif
 
#ifndef _tcout
# ifdef _UNICODE
#  define _tcout wcout
#else
#  define _tcout cout
# endif
#endif
 
...
int cppmain(int argc, _TCHAR* argv[])
{
	std::_tstring helloworld(_T("Hello world!");;
 
	std::_tcout << _T("Message: ") << helloworld.c_str() << std::endl;
 
#ifdef _DEBUG
	std::_tcout << _T("DEBUG: press any key to finish") << std::endl;
	_getch();
#endif
	return 0;
}
 
int _tmain(int argc, _TCHAR* argv[])
{
#ifdef _DEBUG
	OutputDebugString(argv[0]);
	OutputDebugString(_T(" debug: main begins\n"));
	_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF); // | _CRTDBG_CHECK_ALWAYS_DF | _CRTDBG_CHECK_CRT_DF 
	//_CrtSetBreakAlloc(-1);//sets _crtBreakAlloc
	//_crtBreakAlloc=-1;// <- set _crtBreakAlloc using the debugger without recompiling
#endif
	int exitCode;
	__try
	{
		exitCode=cppmain(argc,argv);
	}
	__except(EXCEPTION_EXECUTE_HANDLER)
	{
		std::_tcout << std::endl << "Critical ERROR!!! structured exception handling" << std::endl << std::endl;
		exitCode=EXIT_FAILURE;
	}
#ifdef _DEBUG
	OutputDebugString(argv[0]);
	OutputDebugString(_T(" debug: main ends\n"));
#endif
	return exitCode;
}

[Melem]

Ce n'est pr�vu que lorsqu'on fait du C avec l'api Windows et/ou la crt lib (avec les _tcscpy, _tcscmp, etc).

C'est un peu vrai. Pour �tre plus exact, les TCHAR et fonctions associ�es font partie de la CRT et de l'API Windows qui peuvent toutes �tre utilis�es aussi bien en C qu'en C++. Mais ont est bien d'accord que tout �a se sont des extensions Microsoft hein, �ventuellement disponibles dans d'autres impl�mentations (pratiquement dans toutes les impl�mentations Windows).

Voil� � quoi j'en suis r�duit, c'est pas trop �l�gant je trouve

En effet j'aurais pr�f�r� #define _tcout std::[w]cout par exemple, comme �a _tcout ne ferait pas partie de std.

[JolyLoic]

Donc rien n'est pr�vu en C++ pour compiler un projet enti�rement en unicode ou en ascii. Ce n'est pr�vu que lorsqu'on fait du C avec l'api Windows et/ou la crt lib (avec les _tcscpy, _tcscmp, etc).

Sauf que je ne crois pas aux TCHAR et autre... Pourquoi je n'y crois pas ? simplement parce que pour un vrai projet, on va se retrouver � devoir g�rer dans un seul programme diff�rents types de chars, pour prendre en compte diff�rents types de fichier. Donc pas de TCHAR partout...

Et dans l'autre sens, quel int�r�t sur du nouveau code de devoir g�rer deux versions des ex�cutables, des DLL... non compatibles entre elles ?

Sans compter que toutes ses macros, �a fini par causer des soucis (et si j'ai une variable qui porte le m�me nom qu'une des nombreuses macros d�finies pas VC++ pour g�rer �a ?).

Mon conseil est donc d'oublier ces histoires qui n'ont peut-�tre de l'int�r�t que pour pr�parer un portage d'une vieille appli de char vers wchar_t sans tout casser lors de la phase de portage, et d'�crire directement le code en utilisant wchar_t en interne et en g�rant les diff�rents types d'encodage pour les fichiers externes.

[camboui]

Tu ne fais plus que des applis en wchar_t ?

J'aurais peut-�tre d� y passer plus t�t puisque j'utilise souvent des objets COM qui m'impose cette m.rd. de BSTR (ADO, msxml, etc). D'un autre cot�, on ne travaille qu'en ISO8859-1 (voir UTF8) avec des donn�es sur fichiers qui font quelques gigas. Il est bon d'�viter de trimballer le double de volume qui ne contiendrait que des z�ros en plus sans compter que de nombreux (vieux) outils ne connaissent que les char (en particulier ceux qui manipulent les fichiers texte, justement).

D'un autre cot� il y a un choix politique � faire. Pas simple tout �a...

[JolyLoic]

Tu ne fais plus que des applis en wchar_t ?

Globalment oui. M�me si on g�re de gros volumes de donn�es en UTF-8, l'appli elle m�me est en wchar_t, hors code legacy.

Les vieux outils qui ne connaissent que des char vont de toute mani�re poser des probl�mes d'interface si tu tentes de les faire marcher avec des TCHAR compil�s en mode unicode, donc tu n'�viteras pas avec TCHAR de devoir soit r��crire cette application legacy, soit faire des conversions � l'interface.

Et ils vont poser des probl�mes bien plus important d�s qu'ils devront traiter des donn�es �trang�res...

[camboui]

Extrait de la FAQ (merci Aur�lien)

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
Notez qu'une version Unicode existe aussi pour les flux, afin de les rendre
utilisables avec wstring et wchar_t. Ainsi, on utilisera wcout pour l'affichage,
wcin pour la saisie, wifstream pour la lecture de fichiers, ...
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.

L�, c'est mal parti. On peut pas faire un simple getline() sur un fichier en unicode ?

[Goten]

AFAIK il faut ouvrir les fichiers en binaire pour g�rer les IO en unicode...

[camboui]

Comment se fait-il qu'un d�tail aussi �l�mentaire ne soit pas g�r� ?

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
	std::wofstream of(L"tfile.txt");
	of << L"test Αα Ππ" << std::endl;
	of << L"test Ββ Ωω" << std::endl;

Ce code cr�e un fichier ne contenant que "test ".
C'est l'horreur, c'est �pouvantable, c'est une catastrophe !

On peut sauver nos cpp en unicode ou utf8, c'est toujours �a.

Mais lire des fichiers unicode en binaire c'est ridicule, grotesque !

EDIT: le forum est encore plus ridicule, il n'affiche m�me pas mes beaux caract�res en grec !

[JolyLoic]

L�, c'est mal parti. On peut pas faire un simple getline() sur un fichier en unicode ?

Dans un flux, il faut diff�rencier deux formats de caract�res : Le format �crit dans le flux, et le format que voit le programme qui manipule le flux. Les flux en w... indiquent simplement que le programme va manipuler les flux avec des wchar_t (par exemple, on peut faire wcout << L"Test"), il n'indique rien sur le format des caract�res du flux eux-m�mes.

Pour g�rer ce second aspect, il faut jouer sur les codecvt de la locale utilis�e par les flux. Par exemple, boost fournit un codecvt pour l'UTF8, et cr�er un codecvt pour l'UCS-2 n'est pas tr�s compliqu�. Je m'�tais m�me fait une classe qui va lire les premiers caract�res d'un flux � l'ouverture (le BOM) afin d'imbuer la bonne locale de mani�re transparente (d�sol�, je ne peux pas filer le code, il appartient � ma bo�te).

Je crois qu'en C++0x, il y aura des choses "out of the box" pour �a, et il est possible que tu les aies d�j� si tu utilises un compilo r�cent.

[camboui]

Il semble que tout r�side dans locale et use_facet, mais j'ai rien trouv� dans la faq � ce propos.

EDIT:
Supposons que ufile.txt soit un fichier en unicode

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
	std::wifstream ifs("ufile.txt");
	std::locale loc("unicode");
	ifs.imbue(loc);
	std::wstring s;
	while (std::getline(ifs, s, L'\n'))
		std::wcout << s.c_str() << std::endl;

Exception car "unicode" n'est pas une valeur valide.
Comment connaitre la liste des valeurs "locale" valides ?
Comment utiliser les locales ?
Des exemples concrets ?
Merci

[Sylvain Togni]

Unicode n'est pas un encodage, c'est une table de caract�res.
Les encodages c'est UTF-8, UCS-2, UCS-4, ...
Pour savoir lesquels sont disponibles sur ta machine il faut consulter la doc de ton compilateur et ou biblioth�que standard. Le standard n'impose qu'une seule locale, je crois, c'est la locale "C".

[camboui]

Encodage et jeu de caract�res sont deux choses diff�rentes, en effet. Reste que m�langer les deux quand on parle d'unicode n'est pas trop un soucis, on se comprend

Le probl�me reste entier. On aurait pu s'attendre � un support ais� des streams du C++ pour ouvrir des fichiers textes en d�tectant le BOM (Byte Order Marker) et d'en faire l'extraction correcte, �ventuellement en fonction de la locale si une r�duction wide string vers multibyte string est impos�e.
Mais il n'en est rien.

Je n'�tais d�j� pas fan des stream C++ (lent, compliqu�, mal adapt� aux acc�s binaires), voil� qu'ils ont d�finitivement perdu tout cr�dit � mes yeux.

J'ai fait un petit test:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
	std::cout << 12345.6f << std::endl;
	std::cout.imbue(std::locale("French"));
	std::cout << 12345.6f << std::endl;

Voici l'affichage
12345.6
12�345,6