cppunit-devel — CppUnit Developer Mailing List

Re: [Cppunit-devel] Help: renaming include/extensions/TestSetup.h to TestSetUp.h

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

Woaa!! I'll try not to do that soon again (for info, I was using WinCVS)...

Well, I updated the extensions directory and got a new TestSetUp.h file.

Thanks,
Baptiste

----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: <cpp...@li...>
Sent: Monday, June 11, 2001 8:06 PM
Subject: Re: [Cppunit-devel] Help: renaming include/extensions/TestSetup.h
to TestSetUp.h


> On Mon, Jun 11, 2001 at 08:10:35PM +0200, Bastiaan Bakker wrote:
>
> > Me too. But I seem to have found a workaround by explicitly
> > retrieving revision 1.4, locally removing the tag, update the tag,
> > make some changes to the file and commit.  Now there seems to an
> > alive revision 1.6 in the repository. Please check!
>
> Yup, it checks out.
> Neat trick!
>
> Thanks,
> -Steve
---
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] Help: renaming include/extensions/TestSetup.h to TestSetUp.h

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

On Mon, Jun 11, 2001 at 08:10:35PM +0200, Bastiaan Bakker wrote:

> Me too. But I seem to have found a workaround by explicitly
> retrieving revision 1.4, locally removing the tag, update the tag,
> make some changes to the file and commit.  Now there seems to an
> alive revision 1.6 in the repository. Please check!

Yup, it checks out.
Neat trick!  

Thanks,
-Steve

-- 
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] Help: renaming include/extensions/TestSetup.h to TestSetUp.h

[Bastiaan B. <bas...@li...>]

"Steve M. Robbins" wrote:

> On Mon, Jun 11, 2001 at 06:19:50PM +0200, Baptiste Lepilleur wrote:
> > Quoting Baptiste Lepilleur <gai...@fr...>:
> >
> > Finally got the answer (Those guys are quick!). See
> > http://sourceforge.net/tracker/?func=detail&atid=200001&aid=432067&group_id=1.
>
> Yeah, but they didn't leave a return address!  Grrr.

The tracker is they 'return address'.

>
>
> > If I understood thing well, basically I should not try to rename while playing
> > with case on Windows.
> >
> > Could one of you rename the file ?
>
> I tried: no dice.
>

Me too. But I seem to have found a workaround by explicitly retrieving revision
1.4, locally removing the tag, update the tag, make some changes to the file and
commit.
Now there seems to an alive revision 1.6 in the repository. Please check!




>
> I've added the following comment to your report on sourceforge.
> I assume it will get forwarded to Moorman?
>

Yup, that's the way it works.

Bastiaan

Re: [Cppunit-devel] Help: renaming include/extensions/TestSetup.h to TestSetUp.h

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

On Mon, Jun 11, 2001 at 06:19:50PM +0200, Baptiste Lepilleur wrote:
> Quoting Baptiste Lepilleur <gai...@fr...>:
> 
> Finally got the answer (Those guys are quick!). See 
> http://sourceforge.net/tracker/?func=detail&atid=200001&aid=432067&group_id=1.

Yeah, but they didn't leave a return address!  Grrr.
 
> If I understood thing well, basically I should not try to rename while playing 
> with case on Windows.
> 
> Could one of you rename the file ?

I tried: no dice.

I've added the following comment to your report on sourceforge.
I assume it will get forwarded to Moorman?

-S

After Moorman's first followup, I looked at the archive
again (using a linux CVS client).

Neither file TestSetup.h nor TestSetUp.h appears when
I checkout or update from the repository.

Using "cvs stat", I see a repository revision for
TestSetUp.h, but not for TestSetup.h.

I created an empty TestSetUp.h file, did "cvs add",
and
attempted to commit it.  This fails with same message
mentioned in Baptiste's initial report (which was also from
a linux system):

steve@riemann{extensions}cvs commit -m ''
cvs server: cannot add file `TestSetUp.h' when RCS file
`/cvsroot/cppunit/cppunit/include/cppunit/extensions/TestSetUp.h,v'
already exists
cvs [server aborted]: correct above errors first!
steve@riemann{extensions}


How about if you completely remove TestSetUp.h and
TestSetup.h from the CVS repository, and we'll start over.
(I have a copy of revision 1.4 that I can add back in)

Thanks,
-Steve (smr99)

RE: [Cppunit-devel] Help: renaming include/extensions/TestSetup.h to TestSetUp.h

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

Quoting Baptiste Lepilleur <gai...@fr...>:

Finally got the answer (Those guys are quick!). See 
http://sourceforge.net/tracker/?func=detail&atid=200001&aid=432067&group_id=1.

If I understood thing well, basically I should not try to rename while playing 
with case on Windows.

Could one of you rename the file ?

Thanks,
Baptiste.



> Quoting Bastiaan Bakker <bas...@li...>:
> 
> > Hi Baptiste,
> > 
> > This looks like a server side problem. On my Linux box I could
> > succesfully
> > remove TestSetup.h, but a commit of the addition of TestSetUp.h gave:
> > 
> > ccvs server: cannot add file `TestSetUp.h' when RCS file
> > `/cvsroot/cppunit/cppunit/include/cppunit/extensions/TestSetUp.h,v'
> > already
> > exists
> > cvs [server aborted]: correct above errors first!
> > 
> > TestSetUp.h does not show up with a cvs update or in ViewCVS however. 
> > So this appears to be some corruption of the repository. In any case
> it
> > is
> > not a MSWindows specific bug. 
> > SourceForge folks should investigate further. (We can't since we don't
> > have
> > filesystem access to the repository).
> > Can I leave reporting this in the SF bug tracker to you?
>   I submitted this as bug #432067, under category "Shell/CVS accounts"
> (did not 
> find any category relating to CVS directly).
> 
>   Thanks,
>   Baptiste.
> 
> ---
> Baptiste Lepilleur <gai...@fr...>
> http://gaiacrtn.free.fr/index.html
> Language: English, French
> 
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 



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

Re: [Cppunit-devel] Small patch for cppunit on Alpha Tru64 Unix 5.1

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

Quoting Petter Reinholdtsen <pe...@hu...>:

> [Steve M. Robbins]
> > Petter: what feature is missing if __USE_STD_IOSTREAM is NOT defined?
> > Does the problem appear in Tru64 4.x, by chance?  I have a 4.0f system
> > (on which I could work out a configure test), but no 5.x systems.
> 
> The code refuses to compile if it isn't defined.   Apparently, the C++
> library on Tru64 5.x (I know nothing of Tru64 4.x) require one of two
> defines to allow iostreams to be included.  I choose the Standard C++
> define when compiling cppunit.
> 
> A simple compile test in configure.in should solve the problem.
> 
   I searched RogueWave documentation for that symbol. Here is what I found 
(excerpt of Tools++ 7.1.1 toolread.doc):
----------------------------------------------------------
                   ***************************
                ****   DEC C++ on OSF users   ****
                   ***************************

Tools.h++ is certified for:
  Digital UNIX V4.0F for DEC C++ V6.1, with POSIX threads 
    NOTE: Either DEC or RW Standard Library can be used

1. If you compile Tools.h++ with the DEC Standard Library, Tools.h++ 
will use the old-style iostreams rather than the new iostreams
specified by the published C++ Standard.  The reason for this is that
DEC cxx uses the old iostreams by default and requires the user to
put -D__USE_STD_IOSTREAM in the  cxx command line in order to get
the new iostreams.
----------------------------------------------------------

So it seems to be a platform specific "feature" ;-)

Hope this help,
Baptiste.


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

Re: [Cppunit-devel] Coming changes...

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

On Mon, Jun 11, 2001 at 03:39:49PM +0200, Baptiste Lepilleur wrote:
> Well, I see nobody complained about the coming change.

In my case, the silence was due to the fact that I was away all
weekend, and only just read the messages.  I don't have time to think
them through and say anything intelligent, though.

The changes all sound positive.
I'll wait and see if anything breaks ;-)
 
-- 
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] Small patch for cppunit on Alpha Tru64 Unix 5.1

[Petter R. <pe...@hu...>]

[Steve M. Robbins]
> Petter: what feature is missing if __USE_STD_IOSTREAM is NOT defined?
> Does the problem appear in Tru64 4.x, by chance?  I have a 4.0f system
> (on which I could work out a configure test), but no 5.x systems.

The code refuses to compile if it isn't defined.   Apparently, the C++
library on Tru64 5.x (I know nothing of Tru64 4.x) require one of two
defines to allow iostreams to be included.  I choose the Standard C++
define when compiling cppunit.

A simple compile test in configure.in should solve the problem.

Re: [Cppunit-devel] Small patch for cppunit on Alpha Tru64 Unix 5.1

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

I'll endorse Baptiste's concern: it is extremely dangerous to add
random #defines to the code --- especially ones with leading
underscores!  If the symbol is needed to enable a feature on some
platforms, it can be detected for in the configure script.

Petter: what feature is missing if __USE_STD_IOSTREAM is NOT defined?
Does the problem appear in Tru64 4.x, by chance?  I have a 4.0f system
(on which I could work out a configure test), but no 5.x systems.

-Steve


On Sun, Jun 10, 2001 at 11:53:46AM +0200, Baptiste Lepilleur wrote:
> Is #define __USE_STD_IOSTREAM due to the use of RogueWave STL ? I think I
> already read something about it somewhere (either here or in the forum).
> 
> If that is the case, it would be better to detect the use of those STL (it
> is a crossplatform library) in the configure script and have config.h do
> those define.
> 
> Baptiste.
> 
> ----- Original Message -----
> From: "Petter Reinholdtsen" <pe...@hu...>
> To: <cpp...@li...>
> Sent: Saturday, June 09, 2001 2:25 AM
> Subject: [Cppunit-devel] Small patch for cppunit on Alpha Tru64 Unix 5.1
> 
> 
> >
> > Hello
> >
> > I had to apply the following patch to get cppunit 1.5.5 to compile
> > using Compaq C++ on Tru64 Unix.  Please include it in the next
> > distribution. :-)


-- 
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] Comming changes...

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

Well, I see nobody complained about the comming change.

I'll commit this evening.

Major features:
- test caller can now expect exception (based on Tim Jansen patch)
- TestCase has better support for failure in setUp() and tearOff(). Unit test 
showed that was necessary. Based on Tim Jansen patch, but runTest() and tearOff
() are not called if setUp() failed.
- Exception can be subclassed (still need refining).
- TestAssert changed to namespace (remove compiler internal error on VC++)
- Better portability for HelperMacros, using a TestFactory instead of a 
template member.
- Unit tests for nearly all CppUnit classes (over 80 unit tests). Will probably 
need some refining.

Other than the TestAssert, nothing break existing interface. HelperMacros 
changed the registerTests() prototype though.

Later,
Baptiste.

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

RE: [Cppunit-devel] Help: renaming include/extensions/TestSetup.h to TestSetUp.h

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

Quoting Bastiaan Bakker <bas...@li...>:

> Hi Baptiste,
> 
> This looks like a server side problem. On my Linux box I could
> succesfully
> remove TestSetup.h, but a commit of the addition of TestSetUp.h gave:
> 
> ccvs server: cannot add file `TestSetUp.h' when RCS file
> `/cvsroot/cppunit/cppunit/include/cppunit/extensions/TestSetUp.h,v'
> already
> exists
> cvs [server aborted]: correct above errors first!
> 
> TestSetUp.h does not show up with a cvs update or in ViewCVS however. 
> So this appears to be some corruption of the repository. In any case it
> is
> not a MSWindows specific bug. 
> SourceForge folks should investigate further. (We can't since we don't
> have
> filesystem access to the repository).
> Can I leave reporting this in the SF bug tracker to you?
  I submitted this as bug #432067, under category "Shell/CVS accounts" (did not 
find any category relating to CVS directly).

  Thanks,
  Baptiste.

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

RE: [Cppunit-devel] Help: renaming include/extensions/TestSetup.h to TestSetUp.h

[Bastiaan B. <bas...@li...>]

Hi Baptiste,

This looks like a server side problem. On my Linux box I could succesfully
remove TestSetup.h, but a commit of the addition of TestSetUp.h gave:

ccvs server: cannot add file `TestSetUp.h' when RCS file
`/cvsroot/cppunit/cppunit/include/cppunit/extensions/TestSetUp.h,v' already
exists
cvs [server aborted]: correct above errors first!

TestSetUp.h does not show up with a cvs update or in ViewCVS however. 
So this appears to be some corruption of the repository. In any case it is
not a MSWindows specific bug. 
SourceForge folks should investigate further. (We can't since we don't have
filesystem access to the repository).
Can I leave reporting this in the SF bug tracker to you?

Thanks,

Bastiaan


> -----Oorspronkelijk bericht-----
> Van: Baptiste Lepilleur [mailto:gai...@fr...]
> Verzonden: Monday, June 11, 2001 1:01 PM
> Aan: Cpp Unit Develpment Mailing List
> Onderwerp: [Cppunit-devel] Help: renaming 
> include/extensions/TestSetup.h
> to TestSetUp.h
> 
> 
> 
> I tried to rename TestSetup.h to TestSetUp.h for consistency 
> with the naming 
> scheme applied in CppUnit ( the setUp() method of TestCase ).
> 
> When I tried to do this on Windows, I've got an error message 
> when commiting 
> the new TestSetUp file (that's why there is weird revisions there).
> 
> Here is what I did:
> - remove TestSetup.h
> - commit
> - added TestSetUp.h  (Ok, til there)
> - commit : got an error, can fstat TestSetup.h...
> 
> I'd like someone to try this on a unix box (windows does not 
> differenciate 
> case).
> 
> Don't worry about breaking anything, the file can't be 
> compiled anyway (I fixed 
> this, will be in my next commit).
> 
> Thanks,
> Baptiste.
> 
> ---
> Baptiste Lepilleur <gai...@fr...>
> http://gaiacrtn.free.fr/index.html
> Language: English, French
> 
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
> 

[Cppunit-devel] Help: renaming include/extensions/TestSetup.h to TestSetUp.h

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

I tried to rename TestSetup.h to TestSetUp.h for consistency with the naming 
scheme applied in CppUnit ( the setUp() method of TestCase ).

When I tried to do this on Windows, I've got an error message when commiting 
the new TestSetUp file (that's why there is weird revisions there).

Here is what I did:
- remove TestSetup.h
- commit
- added TestSetUp.h  (Ok, til there)
- commit : got an error, can fstat TestSetup.h...

I'd like someone to try this on a unix box (windows does not differenciate 
case).

Don't worry about breaking anything, the file can't be compiled anyway (I fixed 
this, will be in my next commit).

Thanks,
Baptiste.

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

Re: [Cppunit-devel] Subclassing Exception class for better test failure report

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

Yes.
If you remember the mail that I wrote a while back, this is the second
option for unicode: having a "string" class in the cppunit nameclass that is
an alias to either std::string or std::wstring. That solution also fit well
with the <sstream>/ostringstream problem.

The method expectionType() would be a victim to that change...

I will rise the unicode problem once the basic will be cleaned up (config,
core stuff working correctly). Should not be so long. I'm nearly done
writing unit tests (there is 72 tests by now and they cover most of the
functionnalities).

Baptiste.

----- Original Message -----
From: "Michael Arnoldus" <ch...@mu...>
To: <cpp...@li...>
Sent: Sunday, June 10, 2001 8:24 PM
Subject: Re: [Cppunit-devel] Subclassing Exception class for better test
failure report


Just a small point - I would like to be able to use CppUnit in Unicode
projects, so I think it needs some generic string class which chances
dependent on using Unicode or not. It could be a simple typedef to
std::string or std::wstring.

    Michael Arnoldus
----- Original Message -----
From: "Baptiste Lepilleur" <bl...@cl...>
To: "Cpp Unit Develpment Mailing List" <cpp...@li...>
Sent: Saturday, June 10, 2000 2:15 PM
Subject: [Cppunit-devel] Subclassing Exception class for better test failure
report


>     I want to allow library users and cppunit to subclass the Exception
> class.
>
>     First purpose for this would be to have a NotEqualException which
would
> take two strings in the constructor (acual and expected), allowing better
> error report (put the text on different line, on different edit filed in a
> GUI...).
>
>    Further purpose is to allow users of the library to "create" their one
> assertions and capture more information, while still being able to use
> cppunit framework.
>
>     To do this we need:
>     - be able to duplicate any instance of Exception (or subclassed
> Exception)
>     - identify the actual Exception type so we can downcast if allow.
>
>     To do this, I propose to:
>     - add "public virtual Exception *clone() const" method which returns a
> copy of the Exception.
>     - add "protected virtual std::string exceptionType() const" method
which
> returns a string that identify the exception type (the most extensible and
> portable way I can think of).
>     - add "public static bool isInstanceOf( Exception &e )" method to each
> class which inherits Exception. This method returns true if
exceptionType()
> return the correct identifier string.
>
>     I'd like to be able to report assertEqual() in a better way soon, so
> feedback is welcome. A simple string work well for simple data, but when
you
> are comparing data structure, it's unreadable.
>
>     Thanks,
>     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).
>
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
>
>
>


_______________________________________________
Cppunit-devel mailing list
Cpp...@li...
http://lists.sourceforge.net/lists/listinfo/cppunit-devel

Re: [Cppunit-devel] Subclassing Exception class for better test failure report

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

Just a small point - I would like to be able to use CppUnit in Unicode =
projects, so I think it needs some generic string class which chances =
dependent on using Unicode or not. It could be a simple typedef to =
std::string or std::wstring.

    Michael Arnoldus
----- Original Message -----=20
From: "Baptiste Lepilleur" <bl...@cl...>
To: "Cpp Unit Develpment Mailing List" =
<cpp...@li...>
Sent: Saturday, June 10, 2000 2:15 PM
Subject: [Cppunit-devel] Subclassing Exception class for better test =
failure report


>     I want to allow library users and cppunit to subclass the =
Exception
> class.
>=20
>     First purpose for this would be to have a NotEqualException which =
would
> take two strings in the constructor (acual and expected), allowing =
better
> error report (put the text on different line, on different edit filed =
in a
> GUI...).
>=20
>    Further purpose is to allow users of the library to "create" their =
one
> assertions and capture more information, while still being able to use
> cppunit framework.
>=20
>     To do this we need:
>     - be able to duplicate any instance of Exception (or subclassed
> Exception)
>     - identify the actual Exception type so we can downcast if allow.
>=20
>     To do this, I propose to:
>     - add "public virtual Exception *clone() const" method which =
returns a
> copy of the Exception.
>     - add "protected virtual std::string exceptionType() const" method =
which
> returns a string that identify the exception type (the most extensible =
and
> portable way I can think of).
>     - add "public static bool isInstanceOf( Exception &e )" method to =
each
> class which inherits Exception. This method returns true if =
exceptionType()
> return the correct identifier string.
>=20
>     I'd like to be able to report assertEqual() in a better way soon, =
so
> feedback is welcome. A simple string work well for simple data, but =
when you
> are comparing data structure, it's unreadable.
>=20
>     Thanks,
>     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).
>=20
>=20
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
>=20
>=20
>=20

[Cppunit-devel] synchronization and TestResult

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

    I'm writing the unit tests for the major classes of CppUnit.

    While writing test for TestResult, I stumbled uppon:

std::vector<TestFailure *>&
  TestResult::failures ()
{ 
  ExclusiveZone zone (m_syncObject); 
  return m_failures; 
}

    While the  method is  synchronized, it returns a reference on the vector making the synchronization useless.

    Changing this to:
std::vector<TestFailure *>  TestResult::failures ()

    would solve the problem. Returning by value ensure that the returned vector will stay unmodified.

   Anybody see a better solution to this problem ?

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

[Cppunit-devel] toString() is not used...

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

    Well, I looked around in the code, and the method toString() which is
defined in most of the classes does not seem to be used (getName() is used
instead).

    Since it is not used, why  not remove it ? I think this is a leftover
from the junit port, but I don't see any use for it.

    Having a toString() and a getName() is confusing for newbies (I remember
I was confused at first).

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

[Cppunit-devel] assertEquals with arguments of different type

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

    Is there a reason why assertEquals could not take arguments of different
type (though compatible) ?

    Earlier today, I was comparing an int with a size_t, and I had to cast
the size_t into an int. Quite bothersome when it could be done
automatically.

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

[Cppunit-devel] Subclassing Exception class for better test failure report

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

    I want to allow library users and cppunit to subclass the Exception
class.

    First purpose for this would be to have a NotEqualException which would
take two strings in the constructor (acual and expected), allowing better
error report (put the text on different line, on different edit filed in a
GUI...).

   Further purpose is to allow users of the library to "create" their one
assertions and capture more information, while still being able to use
cppunit framework.

    To do this we need:
    - be able to duplicate any instance of Exception (or subclassed
Exception)
    - identify the actual Exception type so we can downcast if allow.

    To do this, I propose to:
    - add "public virtual Exception *clone() const" method which returns a
copy of the Exception.
    - add "protected virtual std::string exceptionType() const" method which
returns a string that identify the exception type (the most extensible and
portable way I can think of).
    - add "public static bool isInstanceOf( Exception &e )" method to each
class which inherits Exception. This method returns true if exceptionType()
return the correct identifier string.

    I'd like to be able to report assertEqual() in a better way soon, so
feedback is welcome. A simple string work well for simple data, but when you
are comparing data structure, it's unreadable.

    Thanks,
    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] Macro for crossplatform development

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

----- Original Message -----
From: "Baptiste Lepilleur" <gai...@fr...>
To: "Cpp Unit Develpment Mailing List" <cpp...@li...>
Sent: Friday, June 08, 2001 6:56 PM
Subject: [Cppunit-devel] Macro for crossplatform development


>     Steve talking about the macros got me thinking. The main reason why
they
> are an extension is that they use template member methods which is not
very
> portable.
>
>     Thinking a bit more, I realised that the macro where the way to use
the
> best of your platform: if you have RTTI, then it will be used, if you
don't
> then it won't. You can get the best of your platform without giving up
> portability.
>
>     Here I propose a way to get ride of that template member method.
    This can't work since registerTests() is a static method (dohh!). I use
a TestFactory instead that is passed to registerTests(). Work just the same
otherwise.

    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] config.h proposal

[Bastiaan B. <bas...@li...>]

Baptiste Lepilleur wrote:

> > > In this scenario, if HAVE_CONFIG_H is defined we include <config.h> in
> > > <cppunit/Portability.h> ...
> >
> > If you are suggesting that an installed header has
> >
> > #if HAVE_CONFIG_H
> > #include <config.h>
> > #endif
> >
> > then I am completely against it.  I need to be able to use CppUnit
> > in other projects, some of which use autoconf and therefore define
> > HAVE_CONFIG_H.  The behaviour of CppUnit should not change based on
> > whether or not I use autoconf in my project.
>

It should change behaviour, but only detect potential problems, due to
differences between the CppUnit config and the application config. But as I
said the idea is broken, so please forget it.

>
>     I don't really see a need for HAVE_CONFIG_H:
>     If we don't detect VC++ 6.0, C++ builder..., then we default to
> <config.h>.
>     If needed, anoher project specific symbol such as CPPUNIT_HAVE_CONFIG_H
> could be used to force the use of config.h. This symbol would need to be
> defined in each user project.
>

When autconf builds it defines HAVE_CONFIG_H to indicate the availability of
<config.h>. We don't use this macro for CppUnit compilation.  Please forget
about it.

Bastiaan

Re: [Cppunit-devel] config.h proposal

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

> > In this scenario, if HAVE_CONFIG_H is defined we include <config.h> in
> > <cppunit/Portability.h> ...
>
> If you are suggesting that an installed header has
>
> #if HAVE_CONFIG_H
> #include <config.h>
> #endif
>
> then I am completely against it.  I need to be able to use CppUnit
> in other projects, some of which use autoconf and therefore define
> HAVE_CONFIG_H.  The behaviour of CppUnit should not change based on
> whether or not I use autoconf in my project.

    I don't really see a need for HAVE_CONFIG_H:
    If we don't detect VC++ 6.0, C++ builder..., then we default to
<config.h>.
    If needed, anoher project specific symbol such as CPPUNIT_HAVE_CONFIG_H
could be used to force the use of config.h. This symbol would need to be
defined in each user project.

>
> >                         ...  and compare the values of USE_BLA and
> > CPPUNIT_USE_BLA for incompatible differences.
> >
> > Even though there will be no differences when compiling CppUnit, we
still
> > need to have the config.h file.
> > Actually, now that I'm writing this down, I see it's a dumb idea: you
don't
> > know which configuration checks the application performs because
autoconf is
> > dumb enough not to tell you wether a feature is not present or the test
has
> > not been performed. Both cases end up with HAVE_BLA undefined, grr.
>
> There are further problems.  One might have built CppUnit using compiler
> X and then be using it in another project with compiler Y.  The two
> compilers can have different idiosyncracies, which will be reflected
> in the config files for CppUnit and the project using it.
>
>
> > So let's move include/config.h to config/.
>
> OK.
>
>
> > > 2.  We could stick with a (more traditional?) <cppunit/config.h> if
> > > the auto-generated portability header uses the same naming scheme
> > > as the others, say "include/cppunit/config-auto.h".  In other words,
> >
> > OK, sounds fair. It makes clear config-auto.h and config-msvc6.h, etc.
are
> > on the same level.
> >
> > > <cppunit/config.h> takes the role of the file that you called
> > > <cppunit/portability.h>, and "auto" is just another platform.
> > >
> >
> > Because of the confusion the config.h name already has caused, I rather
> > avoid it. People may think that it is some product of autoconf, which it
> > isn't. Also I hope the capital P in <cppunit/Portability.h> may give
people
> > a hint that it is a C++ header, not a C one.
>
> Ah.  Well, the meaning of the capital 'P' completely escaped this person
:-)
> I'm completely used to having capital letters in C header names.
>
> I don't think the name is going to matter much to the user of CppUnit.
> A user will never have to include it directly, as I understand things.
> Only CppUnit headers will include it.  Right?
>
> -S
>
> --
> 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...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
>

Re: [Cppunit-devel] Small patch for cppunit on Alpha Tru64 Unix 5.1

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

Is #define __USE_STD_IOSTREAM due to the use of RogueWave STL ? I think I
already read something about it somewhere (either here or in the forum).

If that is the case, it would be better to detect the use of those STL (it
is a crossplatform library) in the configure script and have config.h do
those define.

Baptiste.

----- Original Message -----
From: "Petter Reinholdtsen" <pe...@hu...>
To: <cpp...@li...>
Sent: Saturday, June 09, 2001 2:25 AM
Subject: [Cppunit-devel] Small patch for cppunit on Alpha Tru64 Unix 5.1


>
> Hello
>
> I had to apply the following patch to get cppunit 1.5.5 to compile
> using Compaq C++ on Tru64 Unix.  Please include it in the next
> distribution. :-)
>

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

[Cppunit-devel] A TestCaller that catch an expected exception

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

I plan to add a test caller that catch an expected exception type. There is
a patch on sourceforge that does that but it's doing it using RTTI.

Here is the meaningful part of the patch:

+  /// dummy exception for TestCaller templates when no exception is
expected
+  class NO_EXCEPTION {
+  };

+  template <class Fixture, class ExpectedException = NO_EXCEPTION>
     class TestCaller : public TestCase


[...]
       protected:
         void runTest ()


-          (m_fixture.get ()->*m_test)();
+          try {
+            (m_fixture.get ()->*m_test)();
+          }
+          catch(ExpectedException e) {
+            return;
+          }
+          catch(...) {
+     throw;
+          }
+

// ==> the RTTI part:
+          if (typeid(ExpectedException) != typeid(NO_EXCEPTION)) {
+    string s = "Expected exception ";
+    s += typeid(ExpectedException).name();
+    s += " from ";
+    s += getName();
+    s += " but got none";
+    throw Exception(s);
+   }
         }

    What's I'm planning is basically the same thing, though the
"NO_EXCEPTION" detection will be done using traits specialization to ensure
portabilty.

    I'll also add the matching macro to HelperMacros.h:

CPPUNIT_TEST_EXCEPTION( testMethod, expectedExceptionType )

    Anyone see something wrong ?

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

[Cppunit-devel] Small patch for cppunit on Alpha Tru64 Unix 5.1

[Petter R. <pe...@hu...>]

Hello

I had to apply the following patch to get cppunit 1.5.5 to compile
using Compaq C++ on Tru64 Unix.  Please include it in the next
distribution. :-)

diff -cr /store/store/palantir/cppunit/src-1.5.5/src/cppunit/TextTestResult.cpp src-1.5.5-alphadec5/src/cppunit/TextTestResult.cpp
*** /store/store/palantir/cppunit/src-1.5.5/src/cppunit/TextTestResult.cpp	Thu Jun  7 10:19:51 2001
--- src-1.5.5-alphadec5/src/cppunit/TextTestResult.cpp	Sat Jun  9 02:15:28 2001
***************
*** 1,3 ****
--- 1,7 ----
+ // Needed on Tru64 Unix 5.1 to choose if pre-ANSI or ANSI iostreams should
+ // be used.
+ #define __USE_STD_IOSTREAM
+ 
  #include <iostream>
  #include "cppunit/TextTestResult.h"
  #include "cppunit/Exception.h"
***************
*** 7,13 ****
  namespace CppUnit {
  
  std::ostream& 
! CppUnit::operator<< (std::ostream& stream, TextTestResult& result)
  { 
    result.print (stream); return stream; 
  }
--- 11,17 ----
  namespace CppUnit {
  
  std::ostream& 
! operator<< (std::ostream& stream, TextTestResult& result)
  { 
    result.print (stream); return stream; 
  }
diff -cr /store/store/palantir/cppunit/src-1.5.5/examples/hierarchy/main.cpp src-1.5.5-alphadec5/examples/hierarchy/main.cpp
*** /store/store/palantir/cppunit/src-1.5.5/examples/hierarchy/main.cpp	Thu Jun  7 10:19:49 2001
--- src-1.5.5-alphadec5/examples/hierarchy/main.cpp	Sat Jun  9 02:16:23 2001
***************
*** 1,3 ****
--- 1,5 ----
+ #define __USE_STD_IOSTREAM
+ 
  #include "cppunit/TestRegistry.h"
  #include "cppunit/TextTestResult.h"
  #include "cppunit/TestSuite.h"
diff -cr /store/store/palantir/cppunit/src-1.5.5/include/cppunit/Exception.h src-1.5.5-alphadec5/include/cppunit/Exception.h
*** /store/store/palantir/cppunit/src-1.5.5/include/cppunit/Exception.h	Thu Jun  7 10:19:50 2001
--- src-1.5.5-alphadec5/include/cppunit/Exception.h	Sat Jun  9 02:09:56 2001
***************
*** 12,18 ****
     *
     */
  
!   class Exception : public exception
    {
      public:
        Exception (std::string  message    = "", 
--- 12,18 ----
     *
     */
  
!   class Exception : public std::exception
    {
      public:
        Exception (std::string  message    = "", 
***************
*** 20,26 ****
          std::string  fileName   = UNKNOWNFILENAME);
        Exception (const Exception& other);
  
!       virtual             ~Exception ();
  
        Exception&   operator= (const Exception& other);
  
--- 20,26 ----
          std::string  fileName   = UNKNOWNFILENAME);
        Exception (const Exception& other);
  
!       virtual             ~Exception () throw();
  
        Exception&   operator= (const Exception& other);
  
diff -cr /store/store/palantir/cppunit/src-1.5.5/src/cppunit/Exception.cpp src-1.5.5-alphadec5/src/cppunit/Exception.cpp
*** /store/store/palantir/cppunit/src-1.5.5/src/cppunit/Exception.cpp	Thu Jun  7 10:19:50 2001
--- src-1.5.5-alphadec5/src/cppunit/Exception.cpp	Sat Jun  9 02:11:38 2001
***************
*** 23,29 ****
  
  
  /// Destruct the exception
! CppUnit::Exception::~Exception ()
  {}
  
  
--- 23,29 ----
  
  
  /// Destruct the exception
! CppUnit::Exception::~Exception () throw ()
  {}
  
  
diff -cr /store/store/palantir/cppunit/src-1.5.5/src/cppunit/TestCase.cpp src-1.5.5-alphadec5/src/cppunit/TestCase.cpp
*** /store/store/palantir/cppunit/src-1.5.5/src/cppunit/TestCase.cpp	Thu Jun  7 10:19:51 2001
--- src-1.5.5-alphadec5/src/cppunit/TestCase.cpp	Sat Jun  9 02:10:31 2001
***************
*** 31,37 ****
      result->addFailure (this, copy);
      
    }
!   catch (exception& e) {
      result->addError (this, new Exception (e.what ()));
      
    }
--- 31,37 ----
      result->addFailure (this, copy);
      
    }
!   catch (std::exception& e) {
      result->addError (this, new Exception (e.what ()));
      
    }