Re: passing char * to dll

Historical note: The first use of multibyte character sets goes back decades, pre-computer
even. Think of the "shift" key on a mechanical typewriter...
joe

On Sun, 9 Mar 2008 07:50:35 -0000, "David Webber" <dave@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:


"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
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Loading