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

[Baptiste L. <gai...@fr...>]

Quoting Michael Arnoldus <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).

  So what you really want is a version of cppunit.lib and testrunner.lib that 
are compiled against the unicode version of the CRT. Not version of CppUnit 
that USE unicode.

  While linked to the unicode library, CppUnit could stick to std::string. The 
only change would be in MFC TestRunner that would need to convert 
Exception::what() to the right type (but that can be handled automatically by 
the MFC CString if I remember well).

> 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?

  The generic string class is only Unicode. But you have other classes to deal 
with legacy char *. That class can construct from const char *, and convert to 
char *. Encoder are provided to read many MBCS text encoding.

> 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?).

  I don't agree that our application should be full Unicode. I agree that it 
makes a lot of sense to make your GUI using Unicode (makes i18n a lot easier). 
On the other hand, there are a lot of place where Unicode is not in use. For 
example, our application at work communicates with others applications by 
exchanging EDIFACT files. Those file are ANSI. The modules that create and read 
those file use ANSI string.

  While the future might be Unicode, the future is not yet there. Worth, we are 
in a transition phase were we often have to deal with both unicode, and ansi. A 
lot of tools that exists only know how to deal with ansi files, they don't have 
the first clue about unicode.

  The whole stuff with change a define and all your string change of type 
strike me as wrong. It may be suitable for a library such as MFC where it is 
preferable to use consistenly the same string type across the library. This is 
not the situation we are in our everyday application. We have to deal with and 
use many legacy or third-parties libraries which are still using ansi string. 
We need to be able to manipulate ansi string and unicode string at the same 
time.

  From a library point of view (which CppUnit is), the change your string with 
a define is the easy way out, but not the best way. I see no reason why we 
couldn't have both at the same time (of course we would still have to provide 
version linked against both unicode and ansi CRT library).

  The challenge here, is to find a way to do that. I started paving the road, 
but there still a long way to go (may be not that long ;-) ).

PS: I was not suggesting that Exception store both std::string and 
std::wstring. Exception would likely store std::wstring, but provide both in 
its interface.

  Baptiste.

> 
> Pfhhh - your turn :-)
> 
> Enjoy.
> 
>     Michael Arnoldus.



---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/index.html
Language: English, French