Re: passing char * to dll


"Rami" <rami@xxxxxxxxx> wrote in message news:O%23tFcfagIHA.3780@xxxxxxxxxxxxxxxxxxxxxxx

In the first respond the person suggested using TCHAR or WCHAR/wchar_t
(thanks Mr. Uterberg) and you suggest LPCTSTR as the right type for Unicode.
Can you please elaborate about the difference between the types and what is
really prefered?

char is a single byte thing so there are only 256 different possible values. This makes it difficult to have fonts of more than 256 characters.

[Aside: The first attempt to do better was the "multibyte character set" which uses more than one char to represent some actual characters, but that is now history.]

Unicode is a way of having all possible characters (latin, chinese, arabic, everything) in a single set. Microsoft's fully 32bit operating systems NT4, 2000, XP, Vista, all use unicode internally. (Win98 didn't.) Microsoft's preferred representation is UTF16 in which "most" (take that word with a pinch of salt) characters are represented by a single 16 bit type wchar_t.

So instead of

char szBuffer[] = "Hello there";

you have

wchar_t szBuffer[] = L"Hello there";

(Almost) all the various API functions have separate versions which take char * strings and wchar_t * strings.

Synonyms are: CHAR for char; WCHAR for wchar_t.

To make the transition as painless as possible (ie only very painful instead of fatal <g>) Microsoft invented the transitional type TCHAR. You have

TCHAR szBuffer[] = _T("Hello there");

The idea was that you write your code using TCHAR everywhere and TCHAR is defined to be char. Then you define UNICODE and _UNICODE in your project definitions and TCHAR is redefined to be wchar_t, and it all just goes on working correctly - as long as you have used all the consistent stuff - APIs which take a TCHAR, etc.

The runtime library has sets of functions like

strcmp() takes char
wcscmp() takes wchar_t
_tcscmp() takes TCHAR

The Windows APIs have sets like

FindWindowA() A="Ascii" - takes char
FindWindowW() W="Wide" - takes wchar_t
FindWindow() takes TCHAR

MFC has classes like

CStringA ascii
CStringW wide
CString TCHAR

Nowadays, in VS2005 onwards I think, a new project has UNICODE and _UNICODE defined, and it is interpreting TCHAR as wchar_t from the start.

In the future we will be expected to use wchar_t explicitly and both char and TCHAR will become history, except possibly for very specialised uses.

Those are the basics. There's a lot more to learn. I think support for all of this stuff (in particular CString) was only essentially complete in VS2005.

Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mozartists/mailinglist.htm







.

Quantcast