C testing framework. ASCII/Unicode portable version

[Andriy Palamarchuk]

Alexandre,
  while I'm not pushing using TCHAR.h here, can't
agree with some your arguments.

--- Alexandre Julliard <julliard at winehq.com> wrote:
> Andriy Palamarchuk <apa3a at yahoo.com> writes:
> > Here I don't agree with you. Programming with
> TCHAR is
> > *exactly* the same as programming with WCHAR, but
> with
> > different names. You think once - in WCHAR terms
> and
> > get as a bonus ANSII version!
> 
> You don't think in WCHAR terms. There isn't a single
> real Unicode
> character in your test, it's all purely ASCII.

If you look even more carefully you'll find that my
test does not have a single real ASCII character :-P
Indeed, I do not test text processing there at all. I
use text strings there for:
a) identifying registry keys
b) testing system settings broadcast behaviour
(comparison against empty string)
c) tests description

In *my* test application W and A versions of functions
have exactly the same behaviour and I'm very glad I
don't need to write the same code twice.

> That's the main problem
> with TCHAR, you have to stick to the lower common
> denominator, which
> means no Unicode chars, no multi-byte support, etc.

a) in places where you need unicode characters or
Unicode-specific checks you can use them with #ifdef
_UNICODE. Test strings generator even will help to
eliminate some of such conditionals.

b) multibyte, not one-byte characters are the common
lowest denominator. Converting the test to TCHAR.h I
had to remember that I'm using multi-byte characters.
E.g. in some places I needed to replace sizeof(buf) to
sizeof(buf)/sizeof(_TCHAR).

> > In fact, code became cleaner after I removed "if
> > (has_unicode()) " blocks, A<->W conversions,
> letters
> > "A", "W" from API names. I feel that in this case
> I
> > don't need to "think twice" - once in terms of
> ANSII,
> > the second time - in terms of Unicode.
> 
> But we want people to think twice, and write a test
> adapted to the
> function they are testing; you don't test ASCII and
> Unicode the same
> way, except superficially.

It would be silly for me to separate W and A checks
everywhere if they are different only in a few cases.

> This TCHAR crap is just a marketing tool to let
> Microsoft pretend that
> converting to Unicode is easy; but it's not usable
> in real life 

Nope. Purpose of TCHAR.h is support of compilation of
the same code for both - Unicode and ASCII platforms.
You still have to make the same decisions as with
moving to pure Unicode API.

> how many apps do you know that ship both an A and a
W
> exe?)

 I came across a few OS projects which use TCHAR:
* Tcl - e.g. see 
http://tcl.apache.org/sources/tcl/win/tclWinFCmd.c.html
* XEmacs - this article will be interesting for you:
http://www.xemacs.org/Architecting-XEmacs/windows-I18N.html

You will agree with me - it is difficult to find this
sort of statistics. But many application have separate
binaries for Windows NT and for Windows 95. One of
differences between these binaries can be usage of
Unicode.

> We don't use
> it in Wine, and we must not use it in Wine tests
> either.

We don't use TCHAR in Wine because it does not give us
any advantages. W and A Wine functions can't exist in
parallel universes, they must interact, probably
factor out common behaviour. 

But I can see which advantages we'll have with using
TCHAR with wine tests.

Andriy Palamarchuk

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/