Re: Problem with using char* to return string by reference

<swtbase@gmail.com> ha scritto nel messaggio
news:525193ae-01eb-4b0b-a561-90b9ef8768e7@l42g2000hsc.googlegroups.com...


TCHAR is a preprocessor macro that you can use to write code that compiles
in both ANSI/MBCS and Unicode builds.

TCHAR is #defined as 'char' in ANSI/MBCS builds, and as 'wchar_t' in Unicode
builds.

There is a good entry on OldNewThing blog that could be interesting for you:

TEXT vs. _TEXT vs. _T, and UNICODE vs. _UNICODE
http://blogs.msdn.com/oldnewthing/archive/2004/02/12/71851.aspx

However, TCHAR works well with CString, not with STL strings.

If you want a TCHAR-based STL string, you may use a custom typedef:

  typedef std::basic_string< TCHAR > tstring;

This will expand to std::string in ANSI/MBCS builds, and to Unicode strings
std::wstring in Unicode builds.

When you use TCHAR, you must pay very much attention to the fact that
sizeof(TCHAR) = sizeof(char) = 1 byte in ANSI builds, but sizeof(TCHAR) =
sizeof(wchar_t) = 2 bytes in Unicode builds. There are several bugs in codes
because of not enough attention payed to the fact that TCHAR size depends on
build mode.


If you search MSDN e.g. for strcpy, you find here:

http://msdn.microsoft.com/en-us/library/kk6xf663.aspx

that there is a table titled "Generic-Text Routine Mappings".

If you read this table, you find the answer to your question:

TCHAR.H routine: _tcscpy

ANSI: strcpy

Unicode: wcscpy

Similar thing for strcat, etc.

However, as we always write here, you should consider using robust string
classes for string operations (like copy, concatenation, etc.) instead of
those old C-style *dangerous* functions (strcpy, etc.). The problem with
those old C-style functions are buffer overruns, which are a very bad
security enemy.
VS2005 introduced safer versions (like strcpy_s) but they are much less safe
than using robust string classes like CString or std::string/wstring.


Win32 APIs until Vista works fine with TCHAR.
Usually a function like e.g. CreateWindow is actually implemented as two
functions: CreateWindowA for ANSI builds, and CreateWindowW for Unicode
builds. CreateWindow is just a #define, which expands to CreateWindowA or
CreateWindowW basing on build mode.


If you use VC6, you may consider using A2T macro (and use USES_CONVERSION)

e.g.

void DoSomething( char * ansiString )
{
   USES_CONVERSION;
   ...
   TCHAR * tString = A2T( ansiString );

   // Do something with tString
   ...
}

Note that common abbreviation for TCHAR *, char * and wchar_t * are:

  TCHAR * --> LPTSTR
  char * --> LPSTR
  wchar_t * --> LPWSTR

There are const versions, too:

  const TCHAR * --> LPCTSTR
  const char * --> LPCSTR
  const wchar_t * --> LPCWSTR

For more details on ATL 3.0 conversion macros (those supported by VC6), you
may read here:

ATL 3.0 String Conversion Macros
http://msdn.microsoft.com/en-us/library/87zae4a3.aspx#atl30stringconversionmacros

Since Windows Vista, new APIs were introduced, that works *only* in Unicode
mode (i.e. they work with wchar_t*, but not with char*).


Believe me: try using Unicode from the beginning. It is a wise investment,
both in quality of code you buld and for your personal programming
knowledge.

HTH,
Giovanni