cppunit-devel

[Cppunit-devel] 1.6.0 is released!

[Steve M. R. <ste...@vi...>]

I'm happy to report that version 1.6.0 is now available on the
SourceForge web site.

The only significant change from the last snapshot is a last-minute
bugfix from Baptiste.  (The other changes were to doc files.)

The CVS tree is synched up with the release version, and tagged (tag
REL_1_6_0).  My immediate plans are to wait and see what bug reports
come in.  I am prepared to make a 1.6.1 release as soon as necessary,
and generally I plan to keep making 1.6.x releases as necessary to fix
bugs.

In the meanwhile, we should kick around ideas for 1.8.0.  I generally
favour the "release early, release often" policy.  How about the rest
of you?  If we go that route though, we need to be aggressive in
limiting what changes will be made for 1.8.  Let's hear ideas!

-Steve 

P.S.  I haven't yet made a branch in the CVS tree, so let's hold
off on non-bugfix changes until a branch is made.


-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: [Cppunit-devel] 1.6.0 is released!

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

Unicode support would be nice!

Enjoy.

    Michael Arnoldus
----- Original Message ----- 
From: "Steve M. Robbins" <ste...@vi...>
To: "CppUnit Development" <cpp...@li...>
Sent: Monday, September 24, 2001 6:23 AM
Subject: [Cppunit-devel] 1.6.0 is released!


> I'm happy to report that version 1.6.0 is now available on the
> SourceForge web site.
> 
> The only significant change from the last snapshot is a last-minute
> bugfix from Baptiste.  (The other changes were to doc files.)
> 
> The CVS tree is synched up with the release version, and tagged (tag
> REL_1_6_0).  My immediate plans are to wait and see what bug reports
> come in.  I am prepared to make a 1.6.1 release as soon as necessary,
> and generally I plan to keep making 1.6.x releases as necessary to fix
> bugs.
> 
> In the meanwhile, we should kick around ideas for 1.8.0.  I generally
> favour the "release early, release often" policy.  How about the rest
> of you?  If we go that route though, we need to be aggressive in
> limiting what changes will be made for 1.8.  Let's hear ideas!
> 
> -Steve 
> 
> P.S.  I haven't yet made a branch in the CVS tree, so let's hold
> off on non-bugfix changes until a branch is made.
> 
> 
> -- 
> by Rocket to the Moon,
> by Airplane to the Rocket,
> by Taxi to the Airport,
> by Frontdoor to the Taxi,
> by throwing back the blanket and laying down the legs ...
> - They Might Be Giants
> 
> 
> 
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 
> 
> 

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

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

Quoting Michael Arnoldus <ch...@mu...>:
 

> Unicode support would be nice!

  I've been rethinking Unicode support for CppUnit lately. I actually wrote the 
TestRunner for Qt (which is full Unicode) without having to change CppUnit.

  It is much easier to move the unicode problem to the TestRunner. The only 
string that need to be handled at that level are:
  1) filename (I don't think __FILE__ can handle unicode filename anyway)
  2) failure message (might be a problem if you use ASSERT_EQUAL and only work 
with non latin1 string).

  In most case, it should be possible to get around the problem raised by (2). 
Though for some applications it might be tough (Japanese to English translator 
for example). (Note: wouldn't it be possible to encode string using MBCS and 
decode them later to Unicode ?)

  So now the problem would be moved at the TestRunner level, more specifically, 
the MFC TestRunner.
  What issue remain ? 
  - library: does unicode use a different runtime library (I don't remember, 
and don't have the unicode version there) ?
  - adaptability: have the test runner compile with/without unicode support and
convert the string as needed.

  What do you think ?

  Baptiste.

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

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

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

Let me see if I understand you correctly. When not changing anything in =
CppUnit, you are degrading the strings in CppUnit to be simple =
containers which contains "something the TestRunner know what to do =
with" - and currently it just happens to be ASCII strings.

This might work, but I think it should be reflected in the design then - =
f.ex. by letting the TestRunner pass the strings as a pointer to a =
subclass of a specific class (or maybe a template parameter class).

I personnaly do not like a design where a string is something we use to =
stuff  something else into and then decode it again - this way doom =
lies!

You are right __FILE__ are not unicode.

Can you use unicode strings in the assert macros the way you have done =
it?

Yes, unicode use a different runtime library.

A while ago you asked me about Unicode programming on unix. I have found =
an article about unicode on linux: =
http://www-106.ibm.com/developerworks/linux/library/l-linuni.html

I now the first Unicode port for windows I did, was not a very good job. =
I'll be willing to it right, but I need somebody who understands CppUnit =
to talk to about the design.

Enjoy.

    Michael Arnoldus.

----- Original Message -----=20
From: "Baptiste Lepilleur" <gai...@fr...>
To: "Cpp Unit Develpment Mailing List" =
<cpp...@li...>
Sent: Monday, September 24, 2001 1:48 PM
Subject: Re: [Cppunit-devel] Unicode Support (was: 1.6.0 is released!)


> Quoting Michael Arnoldus <ch...@mu...>:
> =20
>=20
> > Unicode support would be nice!
>=20
>   I've been rethinking Unicode support for CppUnit lately. I actually =
wrote the=20
> TestRunner for Qt (which is full Unicode) without having to change =
CppUnit.
>=20
>   It is much easier to move the unicode problem to the TestRunner. The =
only=20
> string that need to be handled at that level are:
>   1) filename (I don't think __FILE__ can handle unicode filename =
anyway)
>   2) failure message (might be a problem if you use ASSERT_EQUAL and =
only work=20
> with non latin1 string).
>=20
>   In most case, it should be possible to get around the problem raised =
by (2).=20
> Though for some applications it might be tough (Japanese to English =
translator=20
> for example). (Note: wouldn't it be possible to encode string using =
MBCS and=20
> decode them later to Unicode ?)
>=20
>   So now the problem would be moved at the TestRunner level, more =
specifically,=20
> the MFC TestRunner.
>   What issue remain ?=20
>   - library: does unicode use a different runtime library (I don't =
remember,=20
> and don't have the unicode version there) ?
>   - adaptability: have the test runner compile with/without unicode =
support and
> convert the string as needed.
>=20
>   What do you think ?
>=20
>   Baptiste.
>=20
> ---
> Baptiste Lepilleur <gai...@fr...>
> http://gaiacrtn.free.fr/index.html
> Language: English, French
>=20
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppunit-devel
>=20
>=20
>=20

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

[Baptiste L. <bl...@cl...>]

----- Original Message -----
From: "Michael Arnoldus" <ch...@mu...>
To: "Cpp Unit Develpment Mailing List" <cpp...@li...>
Sent: Monday, September 24, 2001 3:00 PM
Subject: Re: [Cppunit-devel] Unicode Support (was: 1.6.0 is released!)


>Let me see if I understand you correctly. When not changing anything in
CppUnit, you are degrading the strings in CppUnit to be simple containers
which contains "something the TestRunner know what to do with" - and
currently it just happens to be ASCII strings.

Actually, I was rather suggesting MBCS only as a work around having only
std::string (which should be able to contain MBCS string, right?). My point
was rather that unless you are doing application which essence is to
manipulate Unicode object (dictionnary, translator,...), you can probably
get away with restricting your Unicode string to latin1 for ASSERT_EQUAL and
ASSERT_MESSAGE.

>This might work, but I think it should be reflected in the design then -
f.ex. by letting the TestRunner pass the strings as a pointer to a subclass
of a specific class (or maybe a template parameter class).

Yes, but let's not consider it for now. That solution strike me as wrong
(who know what they would put in a string ;-) ).

>I personnaly do not like a design where a string is something we use to
stuff  something else into and then decode it again - this way doom lies!

Don't know much about MBCS, just that is a way to encode character set
depending on your page (meaning you need to know your page to decode).

>You are right __FILE__ are not unicode.

>Can you use unicode strings in the assert macros the way you have done it?

No. I convert the Unicode string to latin1 in my implementation of
toString(), which is not really a loss since there are just object dump and
I control their content.

>Yes, unicode use a different runtime library.

Managing all those configuration will become a source of headache:
2 DLL config.
2 static config (not yet, but requested)
*2 for unicode
*2 : cppunit and testrunner
=> if cppunit remains the same for unicode and ansi string, there twice
less...

>A while ago you asked me about Unicode programming on unix. I have found an
article about unicode on linux:
http://www-106.ibm.com/developerworks/linux/library/l-linuni.html

I'll try to give it a look. I'm using Qt (http://www.trolltech.com) for now
which implements its one Unicode support (lots better than MFC if I might
say).

>I now the first Unicode port for windows I did, was not a very good job.
I'll be willing to it right, but I need somebody who understands CppUnit to
talk to about the design.

    Nor was it a bad job. The solution could be acceptable (the definition
of the generic string/stream would need to be centralized, but that's it).

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

    Note from that point, I'm just throwing ideas around, hoping to discover
some interesting stuffs...

    I think it should be possible to design something a lots cleaner. Let's
put the fact down:

    1) User define strings that may be Unicode are:
    - result of assertion_traits::toString(), used by ASSERT_EQUAL
    - parameter of ASSERT_MESSAGE

    2) Those strings are just a way to convey additional information with
the test failure.

    Let's ignore the current implementation of ASSERTxxx for now. Let's
imagine that we have:

ASSERT_UNICODE_MESSAGE( unicodeMessage, condition );

    How to we get the unicode string to the TestRunner. The obvious answer
is using Exception, the class used to report the failure detail to the
TestRunner. Once we got that part down, then the remaining elements could be
tackle down.

    So my take would be that the first step toward adding unicode support to
CppUnit would be to add Unicode support to Exception. I believe Exception
should still provide a std::string interface to the failure message (all
TestRunner are not written to support unicode), but should also provide a
std::wstring interface.

    We would have:

    std::string what() const;
    std::wstring unicodeWhat() const

    Constructor would need to be changed to accept std::string or
std::wstring for the message. That would also impact Exception subclass:
NotEqualException take two strings at construction, so two constructors
should also be provided.
(PS:  can we do std::wstring( L"\u306b\u307b" ) ? how to you go inputing
hardcoded unicode string?)

    My guess would be that Exception would store everything as std::wstring
(the wider format). We should also have utility function to from and to
unicode (unicode to ansi could be a dummy convertion: if character code is
not in range 0-255 then replace with '?').

    For user, everything is transparent. TestRunners could use either the
ansi or the unicode version to retrieve information.

    And while I'm at it, I can think of a way to deal with ansi/const char
*conversion:

template<typename StringType>
struct convert_to_wstring
{
  std::wstring toWString( StringType str )
  {
    return str;
  }
};

template<typename StringType>
std::wstring convertToWString( StringType str )
{
    return convert_to_wstring<StringType>( str );
}

And you specialize for const char*, std::string, and possibility other user
define string... That template function could be use anywhere to uniformize
string to wstring (for exemple implementation of assertion_traits that
returns a std::string instead of std::wstring).

The only dark point would be:

      static std::string toString( const T& x )
      {
          OStringStream ost;
          ost << x;
          return ost.str();
      }

    That use an ansi stream. What would be the impact of changing that to a
wide stream ?

    What do you think ?

    Baptiste.
---
Baptiste Lepilleur <gai...@fr...>   http://gaiacrtn.free.fr/index.html
Author of The Text Reformatter, a tool for fanfiction readers and writers.
Language: English, French (Well, I'm French).

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.

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

Re: [Cppunit-devel] 1.6.0 is released!

[Baptiste L. <bl...@cl...>]

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: "CppUnit Development" <cpp...@li...>
Sent: Monday, September 24, 2001 6:23 AM
Subject: [Cppunit-devel] 1.6.0 is released!


> I'm happy to report that version 1.6.0 is now available on the
> SourceForge web site.

    Great! I integrated it to our project at work, it works fine.

> The only significant change from the last snapshot is a last-minute
> bugfix from Baptiste.  (The other changes were to doc files.)
>
> The CVS tree is synched up with the release version, and tagged (tag
> REL_1_6_0).  My immediate plans are to wait and see what bug reports
> come in.  I am prepared to make a 1.6.1 release as soon as necessary,
> and generally I plan to keep making 1.6.x releases as necessary to fix
> bugs.

    Well, there are bugs in cppunittest/TestCallerTest (as well as a few
memory leaks I did not spot last time), is does not check correctly the
expected exception stuff. Should that go in 1.6.1 or 1.8.0 (with the
exception enhancement I proposed in another mail)?

> In the meanwhile, we should kick around ideas for 1.8.0.  I generally
> favour the "release early, release often" policy.  How about the rest
> of you?  If we go that route though, we need to be aggressive in
> limiting what changes will be made for 1.8.  Let's hear ideas!

    What is your definition of often ? once a month, biweekly, weekly ? As
time go, we should strengthen our test suite. Whenever a bug is found, we
should try to write a test for it. I already did it for the TestCaller
thingy.

    Baptiste.
---
Baptiste Lepilleur <gai...@fr...>   http://gaiacrtn.free.fr/index.html
Author of The Text Reformatter, a tool for fanfiction readers and writers.
Language: English, French (Well, I'm French).