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...