Re: [Cppunit-devel] Unicode Support (was: 1.6.0 is released!)

[Michael A. <ch...@mu...>]

I think I am confused. I think I like the idea of considering this unicode
stuff from the beginning.

So, why do we want unicode support in CppUnit? The reason I made the port to
unicode in the first place, was that I was working on project on Windows NT,
which used unicode. Since unicode on windows platforms requires different
runtime libraries, I had to do the port, because linking with both the
unicode and non-unicode libraries gives problems (it uses two different
heaps, so new and delete gets all screwed up).

The way they have thought about the problem at Microsoft is: Unicode is the
future. So NT is written using unicode - but, there are lots of non-unicode
programs out there and there probably will be more, so we give the NT API a
set of non-unicode functions to support those programs. Most of the
non-unicode functions are simple wrappers which convert relevent string
parameters to unicode and then call the unicode function.

Sun seems to think along the same lines since in Java (where the testing
unit is originally from) you can only choose between unicode and unicode.

So - the way I think about character strings in programs is that either I am
using Unicode or I am not! Please note that I might want to use a byte
container in unicode programs, which is why the STL implementation with both
a std::string and a std::wstring is fine.

I think maybe we need to agree (or disagree :-) about general principles
before going deeper ind the code, which is why I haven't commented on your
code-specific suggestions.

So - to make it clear. I don't like the idea of having "conceptually" the
same string in two different representations at the same time. I don't like
interfaces which gives room to unicode and non-unicode at the same time. I
think the model we should use in CppUnit is "either we unittest unicode
functions or we unittest non-unicode functions".

I know nothing about Qt - maybe they have a another (better ?) model for
using unicode?

For me it is ok that I can use only Latin1 strings in ASERT_XXX, if porting
gets a lot easier, but if we adopt the above model, it would seem a bit
strange to unicode users of CppUnit that they are not able to use unicode
everywhere.

>     What bother me, is that it have a global impact on CppUnit, and having
> string that change that way is a source of headache. What the user of
> CppUnit should do ? Use CppUnit::String or CString, or Tools::String
> (typedef to std::string or std::wstring like in CppUnit)....

In Windows there is no problem. CString uses unicode or not, dependent on
the same preproc define that chooses which API (and library) to use. If you
are writing a unicode program using STL, then you are using std::wstring
already. But yes, the Tools::String or CppUnit::String definition might be a
great idea as well.

Lets face it. The people using java do not have a problem, they are locked
to unicode. When using C++ we have the advantage of being able to choose,
which also adds the problem that we have to choose! I don't think CppUnit
can (or should) hide the complexity inherent in this choice. I do think its
fair though that the current users of CppUnit shouldn't be bothered about
unicode problems. So the solution we make should make it possible to
continue to use CppUnit in non-unicode programs without any changes (a
property I think my solution fullfilled - no?).

Pfhhh - your turn :-)

Enjoy.

    Michael Arnoldus.