>This is one place where MSoft got it right. They have
>a macro (TCHAR) that expands into the proper basic type
>depending upon whether you've set the option for single
>byte or multibyte support. Different libraries are
>linked in depending upon the setting.
i have to disagree. i have done extensive Unicode programming, and TCHAR is
a joke, b/c Win9x has essentially zero unicode support. TCHAR has nothing
to do with SBCS vs. DBCS (single-byte character set vs. double-byte
character set). DBCS uses either one byte for a logical character, or two
successive bytes to indicate an extended logical character, depending on
exactly which logical character you want to represent. but the physical
size of a character is still one byte. Unicode uses two bytes for all
characters no matter what, so the data type size for WCHAR is 2 bytes.
TCHAR does not magically change size for DBCS support -- DBCS support is a
way of writing code that transparently allows multi-byte characters inside
an inherently single byte OS. TCHAR expands to "char" or "WCHAR" depending
on whether you have #define UNICODE. from experience i can assure you that
coding using TCHARs does not at all make your code easier to port to
unicode, because as soon as you turn on #define UNICODE to make the TCHAR
become WCHAR, suddenly all your API calls fail on Win9x because the #define
UNICODE forces every "FooBar" API to use the "FooBarW" version instead of
the "FooBarA" version and also changes the underlying size of many structs
(wreaking havoc on routines dealing with persisted data). the key problem
is that only 9 Wide APIs are natively implemented in Win9x, and i know from
experience that at least 6 of them have serious flaws. you end up having to
write a lot of wrapper functions. i won't go into the details, but i've had
a lot of experience doing this professionally. bottom line is, there is no
difference between the data type for SBCS and DBCS.
>For those of -not- using "certain devices", who only
>need the single-byte character support, we shouldn't
>have to pay the overhead of library routines built
>for multi-byte support. Nor should we have to deal
>w/ the issues like this where "char" would be the
>proper type.
the beautiful thing about having APIs be DBCS-aware is that you pay
essentially ZERO overhead. your data is as compact as possible, and in fact
the only time you need to pay a little extra attention to DBCS-ness is when
trying to do "psz--" or "psz++" (and strFoo[i], etc) to walk thru a string
looking for some specific character. as long as you are only doing general
string operations, there really is essentially zero overhead. the
underlying trick is that for DBCS strings, you always have lengths and
counts of "characters" talk in physical bytes instead of in logical
characters. that way, most APIs don't even need anything special to be DBCS
aware. for instance, because of the definition of DBCS works, the standard
StrLen (strlen, etc) API just magically is fully DBCS-aware, without making
any changes to it!
>The prototype for StrChr should be:
>
> StrChr(XCHAR *, XCHAR)
as i mention above, this is not useful. TCHAR/XCHAR does not affect DBCS at
all; it is only useful as a way to *attempt* to make certain parts of a
program be a little bit easier to share single source for both a DBCS
version and a natively Unicode version.
