Re: Unicode strings vs. traditional C strings

Compiler does what you'd expect it to.

Inline...

--
Michael Salamone [eMVP]
Entrek Software, Inc.
www.entrek.com


"*** Dawson" <dd@xxxxxx> wrote in message
news:eqkRmSLTHHA.2212@xxxxxxxxxxxxxxxxxxxxxxx
I'm a newbie who has been looking at WinCE6 for a few days. I was slow to
realize that WinCE is heavily Unicode oriented. Maybe I missed something
or maybe the fact that the development environment is a plugin to VS 2005
obscures that fact. I need to check my understanding ...

char *s1 = "oldString";
is 10 bytes long including the terminator, T or F?


T


wchar_t *s2 = "newString";
is 20 bytes long including the terminator, T or F?


T - almost. You should get a compiler error here. Prefix wide strings /
chars with L. E.g. L"newString"


I can obtain ANSI strings from the outside world and manipulate them
internally with a char *, T or F?

T

It's really only the Win32 API that is primarily UNICODE. So if you do get
ASCII from somewhere and need to pass it to a Win32 API, then you need to
convert to wide (MultiByteToWideChar). And if you get a string back from
Win32 that you need to send out, you may need to convert to ASCII
(WideCharToMultiByte).




T or F - A function such as strchr() for ANSI strings does not exist but I
could easily write my own, e.g.
char *strchr(char *s, char c) {
do {
if(*s == c)
return s;
} while(*s++)
return NULL;
}

All CRT is there - strchr, strcmp, etc. Wide versions, too, like wcschr,
wcscmp. And transmutable char (TCHAR) as in tcschr, tcscmp. Use TEXT macro
for TCHAR literals. E.g. TEXT("newString"). Transmutable means it changes
depending if UNICODE is defined or not at compile time. If it is, TCHAR /
TEXT / etc are wide. Otherwise ASCII.

Caveat - I heard but have not confirmed myself that CRT string functions
were entirely removed from WinCE 6.0 - both standard CRT and wide versions.
If so, there are "safe" replacement functions like strcpy_s, wcscpy_s,
StringCchCopyA, StringCchCopyW.




.

Loading