cppunit-devel — CppUnit Developer Mailing List

RE: [Cppunit-devel] output fix

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

-----Oorspronkelijk bericht-----
Van: Steve M. Robbins [mailto:ste...@vi...]
Verzonden: Thursday, May 24, 2001 5:06 PM
Aan: cpp...@li...
Onderwerp: Re: [Cppunit-devel] output fix


On Wed, May 23, 2001 at 05:06:45PM -0400, Steve M. Robbins wrote:
> There's a consistency bug in the TextTestResult output: normal results
> give a ".", while errors and failures emit a newline after the "E" or "F".

I realized later that this is inaccurate.

For *every* test, a '.' is output.  If the test succeeds, nothing further
is emitted.  If it fails or causes an error, then an 'E' or 'F' is also
output (plus a newline until the patch is applied).

One might prefer to have precisely ONE character emitted per test.

Me too. If I recall correctly this is what JUnit does too.


Myself, I prefer the previous verbose style that printed the test
names as they were executed.  To that end, I have derived a new class
from TestResult.  If you wish to include this as an example or
whatever, be my guest.

Obviously different people want different output. For a nice clean
cutomizable output mechanism it may be worthwhile to look at JUnits'
approach with the TestListener interface. That way we need only one
TestResult class and no derived classes. People can simply add the Listeners
they want to the TestResult. 

-Steve

P.S.  Incidentally, I discovered that simple functions, like
"TestResult::runTests()" that returns the number of tests run, are not
declared "const".  Is that an oversight, or does it have something to
do with the synchronization baggage that TestResult carries?

Well, the synchronization object makes it difficult to make the methods
const. I guess it should be possible if the synchronization object were
declared 'mutable const', but I don't think 'mutable' is properly supported
on all (most?) platforms yet. 
 
Bastiaan


namespace CppUnit {

    class Exception;
    class Test;

    class VerboseTestResult : public TestResult 
    {
    public:
	virtual void startTest     (Test *test) {
	    cerr << test->getName() << endl;
	    TestResult::startTest( test );
	}
	virtual void addError      (Test *test, Exception *e) {
	    cerr << "  Error at " << e->fileName() << ":"
		 << e->lineNumber() << ": "
		 << e->what() << endl;
	    TestResult::addError( test, e );
	}
	    
	virtual void addFailure    (Test *test, Exception *e) {
	    cerr << "  Failure at " << e->fileName() << ":"
		 << e->lineNumber() << ": "
		 << e->what() << endl;
	    TestResult::addFailure( test, e );
	}

	std::ostream& printSummary  (std::ostream& os) {
	    return os << "  #test = " << runTests() 
		      << " #failed = " << testFailures()
		      << " #error = " << testErrors();
	}
    };

    ostream& operator<< ( ostream& os, VerboseTestResult& res ) {
	return res.printSummary(os);
    }

}




-- 
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] assert* macros, revisited

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

On Fri, May 25, 2001 at 02:56:10PM -0700, Townsend, Guy wrote:

> Doesn't really matter to me one way or the other what the prefix is. 

Doesn't matter to me, either.  However, it would be nice if all macros
defined in CppUnit share the same prefix.  As far as I can see, the
only other macros in CppUnit are prefixed by CU_ (CU_TEST_SUITE and
friends).

> However, I don't see the point about assertEquals, as it is really
> CppUnit::TestAssert::assertEquals(). No global namespace polution here.

Ah.  Sorry; I have been advocating a new macro "assertEqual", 

#define CU_assertEqual(expected,actual)\
  (CppUnit::TestAssert::assertEquals ((expected),\
    (actual),__LINE__,__FILE__))

and this is what I was referring to, not the member function of TestAssert.
(Also, I'm suggesting that TestAssert::assertEquals() be a templated function).

-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] assert* macros, revisited

[Townsend, G. <gto...@sh...>]

I was just thinking the same thing this morning. It was starting to bug me
that a standard C++ name like assert() was being taken over, and I might get
a conflict if I really wanted the standard. It takes away from the
flexibility to use the library in any way desired. There doesn't seem to be
any good reason for it, and it is easily changed.

In the readme.html of CppUnit 1.5 was the following paragraph:
-------------
Note: If you use the C++ macro "assert ()" in your code, or include
assert.h, you may have a name clash with CppUnit's assert macro. This can be
remedied by changing the name of the macro to "cu_assert ()" in TestCase.h.
------------

So at least cu_assert() has been mentioned, and maybe some people have used
it. Still a simple search and replace on existing test files though, so the
"breakage" of existing code would be minor. 

Doesn't really matter to me one way or the other what the prefix is. But I
sure agree that it should have one. Conflicts with the C++ standard are
certainly a Bad Idea.

However, I don't see the point about assertEquals, as it is really
CppUnit::TestAssert::assertEquals(). No global namespace polution here.
There are the two macros assertDoublesEqual() and assertLongsEqual, but I'm
not aware of conflicts with those names. Still, they should probably have
prefixes too. Any macros in CppUnit will pollute the global namespace, and
thus should use a prefix.


Guy





-----Original Message-----
From: Steve M. Robbins [mailto:ste...@vi...]
Sent: Wednesday, May 23, 2001 6:34 AM
To: cpp...@li...
Subject: [Cppunit-devel] assert* macros, revisited


Hi,

I have come to the conclusion that grabbing global name space with
assert(), assertEqual(), etc, is a Bad Idea.  Besides clashing with
the standard C assert() macro, it is just plain rude.  ;-)

Other libraries prefix their macros with a standard identifier.
CGAL, for one <www.cgal.org> uses CGAL_assert().  In that tradition,
I wonder if CppUnit should move to CppUnit_assert()?

I should hasten to add that I only suggest to do this gradually.
One plan I came up with is to #define the CppUnit_assert version,
and use 
	#define assert(cond) CppUnit_assert(cond)

for backwards compatibility.  In fact, we could make it a configure
option (--with-toplevel-assert ?).  Those who wish to make sure they
are writing "clean" test cases will be able to disable the old macro
names ("./configure --without-toplevel-assert").

Comments?  

I see now that there are some other macros with a "CU_" prefix.
If that is the desired prefix for CppUnit, then we'd go with 
CU_assert() and CU_assertEqual().

-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


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

[Cppunit-devel] CU_TEST_SUITE and friends

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

Hi,

I discovered these macros yesterday --- they are fantastic!  They make
writing the test case classes a whole lot less tedious.  

I had to change two things to get them to work with GCC, however.  The
first patch is a trivial matter.  I don't know why the two
constructors of AutoRegisterSuite were different, but GCC didn't like
one of them.

The second patch just moves the definition of the suite() method from
CU_TEST_SUITE to CU_TEST_SUITE_END.  GCC gets itself in a knot if the
code has a forward reference to a templated function.  In this case
suite() calls registerTests(), but the latter is only defined after
the CU_TEST_SUITE/CU_TEST/.../CU_TEST_SUITE_END sequence.  Moving the
definition of suite() cures this.

What conclusion should I draw from the fact that these macros are
hiding in the "extensions" directory?  Are they less desirable in some
way that eludes me?  To a novice like me, they appear MORE desirable.
I wish that the "cookbook" had been using them.  I think that would
have lowered my learning curve.

In fact, I have example code, modelled on the cookbook, that uses
these macros.  I'm inclined to re-write the cookbook in the CU_TEST
style and include this code in examples/ as a test program for "make
check".  Shall I send this patch along, or slow down?  I feel a little
like I'm shouting into a void ... are the patches unwelcome?  arriving
too fast?

Regards,
-Steve




Index: AutoRegisterSuite.h
===================================================================
RCS file: /cvsroot/cppunit/cppunit/include/cppunit/extensions/AutoRegisterSuite.h,v
retrieving revision 1.4
diff -u -b -B -r1.4 AutoRegisterSuite.h
--- AutoRegisterSuite.h	2001/05/06 18:19:04	1.4
+++ AutoRegisterSuite.h	2001/05/25 21:20:18
@@ -34,7 +34,7 @@
        */
       AutoRegisterSuite( const std::string &name )
       {
-        TestSuiteFactory *factory = new TestSuiteFactory<TestCaseType>();
+        TestFactory *factory = new TestSuiteFactory<TestCaseType>();
         TestFactoryRegistry::getRegistry( name ).registerFactory( factory );
       }
   };
Index: HelperMacros.h
===================================================================
RCS file: /cvsroot/cppunit/cppunit/include/cppunit/extensions/HelperMacros.h,v
retrieving revision 1.6
diff -u -b -B -r1.6 HelperMacros.h
--- HelperMacros.h	2001/05/23 18:34:54	1.6
+++ HelperMacros.h	2001/05/25 21:20:18
@@ -91,14 +98,6 @@
   private:                                                              \
     typedef ATestCaseType __ThisTestCaseType;                           \
   public:                                                               \
-    static CppUnit::Test *suite()                                       \
-    {                                                                   \
-      __ThisTestCaseType *test =NULL;                                   \
-      CppUnit::TestSuiteBuilder<__ThisTestCaseType>                     \
-          suite __CU_SUITE_CTOR_ARGS( ATestCaseType );                  \
-      __ThisTestCaseType::registerTests( suite, test );                 \
-      return suite.takeSuite();                                         \
-    }                                                                   \
     template<typename TestCaseType>                                     \
     static void                                                         \
     registerTests( CppUnit::TestSuiteBuilder<TestCaseType> &suite,      \
@@ -156,6 +162,14 @@
  */
 #define CU_TEST_SUITE_END()                                             \
 }                                                                       \
+    static CppUnit::Test *suite()                                       \
+    {                                                                   \
+      __ThisTestCaseType *test =NULL;                                   \
+      CppUnit::TestSuiteBuilder<__ThisTestCaseType>                     \
+          suite __CU_SUITE_CTOR_ARGS( ATestCaseType );                  \
+      __ThisTestCaseType::registerTests( suite, test );                 \
+      return suite.takeSuite();                                         \
+    }                                                                   \
   private:
 
 #define __CU_CONCATENATE_DIRECT( s1, s2 ) s1##s2


-- 
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] debian fixes

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

Hi,

I have several suggestions for the debian package.

1. Register the main doxygenerated web page with doc-base,
   rather than the cookbook.  The former links to the latter, anyway.

2. Move the doxygenerated web pages to the debian-approved 
   location /usr/share/doc/cppunit/html.  

3. Installing the "hierarchy" example binary is not useful,
   nor is installing Makefile.in and Makefile.

4. A .cvsignore file would be appreciated.


Below are appended some patches for items 1-3, and a .cvsignore
file that I have been using.

Regards
-Steve


Index: doc-base.cppunit
===================================================================
RCS file: /cvsroot/cppunit/cppunit/debian/doc-base.cppunit,v
retrieving revision 1.1
diff -u -b -B -r1.1 doc-base.cppunit
--- doc-base.cppunit	2001/05/16 09:07:09	1.1
+++ doc-base.cppunit	2001/05/25 21:03:30
@@ -5,7 +5,7 @@
 Section: devel
 
 Format: HTML
-Index: /usr/share/doc/cppunit/cookbook.html
-Files: /usr/share/doc/cppunit/cookbook.html
+Index: /usr/share/doc/cppunit/html/index.html
+Files: /usr/share/doc/cppunit/html/*.html
 
   
Index: rules
===================================================================
RCS file: /cvsroot/cppunit/cppunit/debian/rules,v
retrieving revision 1.1
diff -u -b -B -r1.1 rules
--- rules	2001/05/16 09:07:09	1.1
+++ rules	2001/05/25 21:03:30
@@ -40,7 +40,12 @@
 
 	# Add here commands to install the package into debian/<packagename>
 	$(MAKE) prefix=`pwd`/debian/$(PACKAGENAME)/usr install
+	mkdir -p debian/cppunit/usr/share/doc/cppunit
+	mv debian/cppunit/usr/doc/cppunit-*/html \
+	   debian/cppunit/usr/share/doc/cppunit
+	rm -rf debian/cppunit/usr/doc
 
+
 # Build architecture-independent files here.
 binary-indep: build install
 # We have nothing to do by default.
@@ -52,7 +57,7 @@
 #	dh_installdebconf	
 	dh_installdocs README doc/cookbook.html 
 	dh_installexamples \
-		examples/hierarchy/M* examples/hierarchy/hierarchy \
+		examples/hierarchy/Makefile.am \
 		examples/hierarchy/*.h examples/hierarchy/*.cpp
 	dh_installmenu
 #	dh_installlogrotate



---------------------- cppunit/debian/.cvsignore ----------------------
cppunit
*.debhelper
substvars
files
-----------------------------------------------------------------------


-- 
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] auto-generated files

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

-----Oorspronkelijk bericht-----
Van: Steve M. Robbins [mailto:ste...@vi...]
Verzonden: Wednesday, May 23, 2001 4:32 PM
Aan: cpp...@li...
Onderwerp: Re: [Cppunit-devel] auto-generated files


On Wed, May 23, 2001 at 04:05:20PM +0200, Bastiaan Bakker wrote:

> Yes, you're completely right about that: generated files shouldn't be in
> CVS. Developers are expected to have a proper install of the auto-* tools
> (who hasn't? :-). 
> config.guess, config.sub, ltmain.sh and ltconfig have been removed from
CVS.

Thank you.  That will make "cvs diff" much less painful :-)

I haven't done a thorough sweep, but there are at least three other
"non-source" files still in CVS:

	config/install-sh
	config/missing
	config/mkinstalldirs

Hehe, you can hit reply faster than I can do cvs remove! But they are
already gone too. 
If you find any other derived files to get rid of, please let me know!

Thanks,

Bastiaan
 

[Cppunit-devel] Debian packager joins project

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

Hi all,
 
This message is just to inform you that Christian Leutloff [
leu...@su... <mailto:leu...@su...> ], who
already has been building CppUnit packages for Debian, now has joined the
project. Christian, welcome!
This primarily means that Christian will be maintaining the debian
subdirectory, so if you have any questions / suggestions, etc. about that,
he is your man. Debian packages for CppUnit are available at:
http://packages.debian.org/cppunit/ <http://packages.debian.org/cppunit/> 
 
Regards,
 
Bastiaan
 
 
 

Re: [Cppunit-devel] output fix

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

On Wed, May 23, 2001 at 05:06:45PM -0400, Steve M. Robbins wrote:
> There's a consistency bug in the TextTestResult output: normal results
> give a ".", while errors and failures emit a newline after the "E" or "F".

I realized later that this is inaccurate.

For *every* test, a '.' is output.  If the test succeeds, nothing further
is emitted.  If it fails or causes an error, then an 'E' or 'F' is also
output (plus a newline until the patch is applied).

One might prefer to have precisely ONE character emitted per test.


Myself, I prefer the previous verbose style that printed the test
names as they were executed.  To that end, I have derived a new class
from TestResult.  If you wish to include this as an example or
whatever, be my guest.

-Steve

P.S.  Incidentally, I discovered that simple functions, like
"TestResult::runTests()" that returns the number of tests run, are not
declared "const".  Is that an oversight, or does it have something to
do with the synchronization baggage that TestResult carries?




namespace CppUnit {

    class Exception;
    class Test;

    class VerboseTestResult : public TestResult 
    {
    public:
	virtual void startTest     (Test *test) {
	    cerr << test->getName() << endl;
	    TestResult::startTest( test );
	}
	virtual void addError      (Test *test, Exception *e) {
	    cerr << "  Error at " << e->fileName() << ":"
		 << e->lineNumber() << ": "
		 << e->what() << endl;
	    TestResult::addError( test, e );
	}
	    
	virtual void addFailure    (Test *test, Exception *e) {
	    cerr << "  Failure at " << e->fileName() << ":"
		 << e->lineNumber() << ": "
		 << e->what() << endl;
	    TestResult::addFailure( test, e );
	}

	std::ostream& printSummary  (std::ostream& os) {
	    return os << "  #test = " << runTests() 
		      << " #failed = " << testFailures()
		      << " #error = " << testErrors();
	}
    };

    ostream& operator<< ( ostream& os, VerboseTestResult& res ) {
	return res.printSummary(os);
    }

}




-- 
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] output fix

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

There's a consistency bug in the TextTestResult output: normal results
give a ".", while errors and failures emit a newline after the "E" or "F".

-Steve



2001-05-23  Steve M. Robbins  <st...@ny...>

	* src/cppunit/TextTestResult.cpp (addError, addFailure): Do not
	add newline after output ("E","F", respectively).



Index: src/cppunit/TextTestResult.cpp
===================================================================
RCS file: /cvsroot/cppunit/cppunit/src/cppunit/TextTestResult.cpp,v
retrieving revision 1.2
diff -u -b -B -r1.2 TextTestResult.cpp
--- src/cppunit/TextTestResult.cpp	2001/05/19 11:29:11	1.2
+++ src/cppunit/TextTestResult.cpp	2001/05/23 21:01:43
@@ -16,7 +16,7 @@
 TextTestResult::addError (Test *test, Exception *e)
 {
     TestResult::addError (test, e);
-    std::cerr << "E" << std::endl;
+    std::cerr << "E";
 
 }
 
@@ -24,7 +24,7 @@
 TextTestResult::addFailure (Test *test, Exception *e)
 {
     TestResult::addFailure (test, e);
-    std::cerr << "F" << std::endl;
+    std::cerr << "F";
 
 }
 





-- 
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] auto-generated files

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

On Wed, May 23, 2001 at 04:05:20PM +0200, Bastiaan Bakker wrote:

> Yes, you're completely right about that: generated files shouldn't be in
> CVS. Developers are expected to have a proper install of the auto-* tools
> (who hasn't? :-). 
> config.guess, config.sub, ltmain.sh and ltconfig have been removed from CVS.

Thank you.  That will make "cvs diff" much less painful :-)

I haven't done a thorough sweep, but there are at least three other
"non-source" files still in CVS:

	config/install-sh
	config/missing
	config/mkinstalldirs

> You mention Makefile.in files, as far as I can see, there aren't any in CVS
> at the moment. One had gotten in by accident, but it already has been
> removed.

Yes, I see.  

I guess I had run "automake" between the time it got checked in and
the time it got removed, so I had a "Modified" version showing up each
time I did "cvs update":

	include/cppunit/extensions/Makefile.in

Thanks again,
-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

[Cppunit-devel] bug #424320, getting it closed...

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

    I consider bug #424320 closed. I made the fix (see change log). Could
its status be changed to reflect that ?

    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] Unicode

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

> * adding a function ustring( const char *) to estring.h to construct a
> unicode string from a const char *string.
>   This one is a problem for portability. Mapping from "char *" to unicode
is
> done using WIN32 API.
>   So how is that done on unix. Is there a single API for all Unix to do
the
> mapping ? (I know that QT support unicode and is portable, but not how
> difficult it is to achieve on Unix)

  I looked at how it was done in QT 2.3.0 QString class
(http://www.trolltech.no, worth looking at if you don't know what it is
;-) ).

  If I got the code right, latin1 is converted to unicode by casting the
char to a wchar_t. Since the most common use for this conversion would be
for RTTI names and standard exception messages, they likely would be latin1.
So we could implements this simple conversion for Unix.

  Did I mess up real hard reading the code ?
  What do you think of this solution ?

  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] auto-generated files

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

-----Oorspronkelijk bericht-----
Van: Steve M. Robbins [mailto:ste...@vi...]
Verzonden: Wednesday, May 23, 2001 3:10 PM
Aan: cpp...@li...
Onderwerp: [Cppunit-devel] auto-generated files


Hi,

I have another suggestion about the CVS archive.  

I have a different libtool version than you do (whoever is checking in
the files).  Consequently, I can't build cppunit until I run
"libtoolize".  Among other things, this copies in new versions of the
three files
		config/config.guess
		config/config.sub
		config/ltmain.sh

which means that any "cvs diff" I try to generate is swamped by the
diffs of these three files.

It would be a great help to folks in my situation if you could simply
remove all generated files from CVS.  That includes the three
mentioned above, as well as all the Makefile.in files.

The only reason to commit built files into CVS is if you wish to
cater to developers who don't have all the auto-* tools.  If that
is your reasoning, I can accept it.  However, it is also possible
to simply ask them to start from the latest tarball, and do a 
cvs checkout overtop of it.  (Or I can make tarball snapshots every
night with a cron job...)

Yes, you're completely right about that: generated files shouldn't be in
CVS. Developers are expected to have a proper install of the auto-* tools
(who hasn't? :-). 
config.guess, config.sub, ltmain.sh and ltconfig have been removed from CVS.

You mention Makefile.in files, as far as I can see, there aren't any in CVS
at the moment. One had gotten in by accident, but it already has been
removed. If you encounter more, please let me know.

Thanks,

Bastiaan



-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

[Cppunit-devel] assert* macros, revisited

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

Hi,

I have come to the conclusion that grabbing global name space with
assert(), assertEqual(), etc, is a Bad Idea.  Besides clashing with
the standard C assert() macro, it is just plain rude.  ;-)

Other libraries prefix their macros with a standard identifier.
CGAL, for one <www.cgal.org> uses CGAL_assert().  In that tradition,
I wonder if CppUnit should move to CppUnit_assert()?

I should hasten to add that I only suggest to do this gradually.
One plan I came up with is to #define the CppUnit_assert version,
and use 
	#define assert(cond) CppUnit_assert(cond)

for backwards compatibility.  In fact, we could make it a configure
option (--with-toplevel-assert ?).  Those who wish to make sure they
are writing "clean" test cases will be able to disable the old macro
names ("./configure --without-toplevel-assert").

Comments?  

I see now that there are some other macros with a "CU_" prefix.
If that is the desired prefix for CppUnit, then we'd go with 
CU_assert() and CU_assertEqual().

-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

[Cppunit-devel] documentation fixes

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

Hi,

Here is an updated version of the documentation patch I once sent.

-Steve

P.S.  In the unix community, the file named ChangeLog has adopted a
very standardized format.  Changelog entries must be of the form
"<TAB>* filename: text ..." if the entry pertains to the whole file,
or "<TAB>* filename (id1, id2,...): text ..." if the entry pertains to
certain functions or variables named "id1", "id2", etc.  Several
tools (notably the emacs editor) understand this format and will
highlight it.  

It would be greatly appreciated if this format is maintained for
ChangeLog entries.  See <http://www.red-bean.com/cvs2cl/changelogs.html>
for more detailed suggestions on how and what to log.




2001-05-22  Steve M. Robbins  <st...@ny...>

	* examples/hierarchy/main.cpp: Remove extraneous #includes.

	* doc/other_documentation.dox: Don't try to include CppUnit in
	<a> tag text; Doxygen screws this up.

	* doc/cookbook.html: Fix example code.






Index: examples/hierarchy/main.cpp
===================================================================
RCS file: /cvsroot/cppunit/cppunit/examples/hierarchy/main.cpp,v
retrieving revision 1.8
diff -u -b -B -r1.8 main.cpp
--- examples/hierarchy/main.cpp	2001/04/23 22:19:10	1.8
+++ examples/hierarchy/main.cpp	2001/05/23 13:04:40
@@ -1,7 +1,5 @@
-#include "cppunit/TestRegistry.h"
 #include "cppunit/TextTestResult.h"
 #include "cppunit/TestSuite.h"
-#include "cppunit/Test.h"
 
 #include "BoardGame.h"
 #include "Chess.h"
Index: doc/cookbook.html
===================================================================
RCS file: /cvsroot/cppunit/cppunit/doc/cookbook.html,v
retrieving revision 1.1.1.1
diff -u -b -B -r1.1.1.1 cookbook.html
--- doc/cookbook.html	2000/10/05 18:37:28	1.1.1.1
+++ doc/cookbook.html	2001/05/23 13:04:40
@@ -8,7 +8,12 @@
     <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
   </P>
   <H1>CppUnit Cookbook</H1>
-  <P>Here is a short cookbook to help you get started. </P>
+  <P>
+    Here is a short cookbook to help you get started.
+    Note that all CppUnit types are defined in the CppUnit
+    namespace.  For brevity, the prefix <b>CppUnit::</b>
+    is omitted in the following examples.
+  </P>
   <H2>Simple Test Case</H2>
   <P>
     You want to know whether your code is working. 
@@ -90,9 +95,7 @@
         friend bool operator== (const Complex&amp; a, const Complex&amp; b);
         double      real, imaginary;
         public:
-                    Complex ()  {
-                    real = imaginary = 0.0;
-                    }
+                    Complex ( double r, double i = 0 ) : real(r),imaginary(i) {}
         };
 
         bool operator== (const Complex&amp; a, const Complex&amp; b)
@@ -153,7 +156,7 @@
 <TT><PRE>&#9;class ComplexNumberTest : public TestCase  {
 &#9;private:
         Complex &#9;*m_10_1, *m_1_1; *m_11_2;
-&#9;protected:
+&#9;public:
 &#9;void&#9;&#9;setUp ()  {
 &#9;&#9;&#9;    m_10_1 = new Complex (10, 1);
 &#9;&#9;&#9;    m_1_1  = new Complex (1, 1);
@@ -170,31 +173,33 @@
 &#9;&#9;&#9;    assert (*m_10_1 + *m_1_1 == *m_11_2);
                  &#9;}
 &#9;};</PRE>
-</TT><P>Create and run instances for each test case like this:</P>
-<TT><PRE>&#9;test = new TestCaller&lt;ComplexNumberTest&gt;("testEquality", ComplexNumberTest::testEquality);
-        test->run (); </PRE>
-</TT><P>The second argument to the test caller constructor is the address of a method on ComplexNumberTest. When the test caller is run, that specific method will be run.</P>
-<P>Once you have several tests, organize them into a suite.</P>
+</TT><P>One may create and run instances for each test case like this:</P>
+<TT><PRE>&#9;TestCaller&lt;ComplexNumberTest&gt; test("testEquality", &amp;ComplexNumberTest::testEquality);
+        test.run (); </PRE>
+</TT><P>The second argument to the test caller constructor is the address of a method on ComplexNumberTest. When the test caller is run, that specific method will be run.  This is not a useful thing to do, however, as no diagnostics will be
+    displayed.  One will normally use a TestRunner (see below) to display
+    the results.
+    </P>
+
+    <P>Once you have several tests, organize them into a suite.</P>
 <P>&nbsp;</P>
 <H2>Suite</H2>
 <P>How do you set up your tests so that you can run them all at once?<BR>
 <BR>
-CppUnit provides a TestSuite class that runs any number of TestCases together. For example, to run a single test case, you execute:</P>
-<TT><PRE>&#9;TestResult result;
-&#9;TestCaller&lt;ComplexNumberTest&gt; test ("testAddition", ComplexNumberTest::testAddition);
-&#9;Test.run (&amp;result);</PRE>
-</TT><P>&nbsp;</P>
-<P>To create a suite of two or more tests, you do the following:</P>
+CppUnit provides a TestSuite class that runs any number of TestCases together.
+    We saw, above, how to run a single test case.
+To create a suite of two or more tests, you do the following:</P>
 <TT><PRE>&#9;TestSuite suite;
 &#9;TestResult result;
-&#9;suite.addTest (new TestCaller&lt;ComplexNumberTest&gt;("testEquality", ComplexNumberTest::testEquality));
-&#9;suite.addTest (new TestCaller&lt;ComplexNumberTest&gt;("testAddition", ComplexNumberTest::testAddition));
+&#9;suite.addTest (new TestCaller&lt;ComplexNumberTest&gt;("testEquality", &amp;ComplexNumberTest::testEquality));
+&#9;suite.addTest (new TestCaller&lt;ComplexNumberTest&gt;("testAddition", &amp;ComplexNumberTest::testAddition));
 &#9;suite.run (&amp;result);
            </PRE>
 </TT><P>TestSuites don't only have to contain callers for TestCases. They can contain any object that implements the Test interface. For example, you can create a TestSuite in your code and I can create one in mine, and we can run them together by creating a TestSuite that contains both: </P>
 <TT><PRE>&#9;TestSuite suite;
-&#9;suite.addTest (ComplexNumberTest.suite ());
-&#9;suite.addTest (SurrealNumberTest.suite ());
+&#9;TestResult result;
+&#9;suite.addTest (ComplexNumberTest::suite ());
+&#9;suite.addTest (SurrealNumberTest::suite ());
 &#9;suite.run (&amp;result);</PRE>
 </TT><P>&nbsp;</P>
 <H2>TestRunner</H2>
Index: doc/other_documentation.dox
===================================================================
RCS file: /cvsroot/cppunit/cppunit/doc/other_documentation.dox,v
retrieving revision 1.2
diff -u -b -B -r1.2 other_documentation.dox
--- doc/other_documentation.dox	2001/04/14 00:51:17	1.2
+++ doc/other_documentation.dox	2001/05/23 13:04:40
@@ -16,7 +16,7 @@
 
  \section _usage Usage
  Take a look into 
- <a href="../cookbook.html">the CppUnit cookbook</a>.
+ the CppUnit <a href="../cookbook.html">cookbook</a>.
  It gives a quick start into using this 
  testing framework.
  For a discussion on CppUnit, check 




-- 
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] auto-generated files

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

Hi,

I have another suggestion about the CVS archive.  

I have a different libtool version than you do (whoever is checking in
the files).  Consequently, I can't build cppunit until I run
"libtoolize".  Among other things, this copies in new versions of the
three files
		config/config.guess
		config/config.sub
		config/ltmain.sh

which means that any "cvs diff" I try to generate is swamped by the
diffs of these three files.

It would be a great help to folks in my situation if you could simply
remove all generated files from CVS.  That includes the three
mentioned above, as well as all the Makefile.in files.

The only reason to commit built files into CVS is if you wish to
cater to developers who don't have all the auto-* tools.  If that
is your reasoning, I can accept it.  However, it is also possible
to simply ask them to start from the latest tarball, and do a 
cvs checkout overtop of it.  (Or I can make tarball snapshots every
night with a cron job...)

-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

Re: [Cppunit-devel] TestSuiteBuilder & type info...

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

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

> Baptiste Lepilleur wrote:
> 
> OK, finally I start to understand what you mean! :-)
> I've mostly been doing Java programming the last few years. No generics
> there,  so
> I'm not too intimate with those and some other C++ features.
> Thanks for the C++ Journal link. Interesting information, the author is
> pretty
> sick bastard though: calling writing a dozen basic_string
> implementations 'fun'
> :-D
> I must be a C++ wimp ;-)
  Well, I discovered this aspect of generic programming not so long ago and I 
see unit testing as a perfect way to solve many of the problems I have when 
pushing template this far (compilation error that appear only when you us the 
method, testing...). That's why I pushing that aspect forward.

> I don't care what people do on their own projects: they should be free
> to keep any
> platform dependencies they want.
> My worry is that the more platform dependent features get into CppUnit
> the more
> difficult it becomes to maintain:  people on other platforms cannot
> check whether
> they break these features, more code than neccessary may come to depend
> on it,
> etc. ,etc.
  From what you said it is possible to compile with RTTI enabled for g++. Even 
if the result is not readable, knowing that it compile is a first step.
  I added a configuration to compile without RTTI on VC++, that's how I 
discovered that the AutoRegisterSuite did not work (that's fixed now). You 
could do the same for Unix.

  I was thinking of doing unit test to test cppunit. I once found the test 
cases for Junit, but I looked for them and couldn't find them !

  Such unit tests would allow us to test the many aspects of cppunit ;-) (the 
current example barely skim the surface).

> OK, do what's necessary for the RTTI features. Now that I understand how
> it may be
> useful, I would not want to keep excluding it from the project.
  This is in CVS now.

> 
> Indeed, it isn't. I'll see if I can get the reasoning behind from one of
> the g++
> folks.
  Yes that would be interesting. 

> > you are doing multiplatform. We just have to stick it somewhere in the
> > documentation (I'll put it in TestSuiteBuilder at the current time).
> But I
> > would put it somewhere else. This fact is binded to the
> CU_USE_TYPEINFO macro,
> > not TestSuiteBuilder. Any Suggestions on where to put that ?
> >
> 
> With the TypeInfoHelper class?
  Yes I'll put it there for now, but It's buried pretty deep. I would like to 
have something more like a build guide that say "using CU_USE_TYPEINFO you can 
do this and that, but you lose multiplatform." I doubt the user would bother 
reading each class documentation. He doesn't even use TypeInfoHelper.
  
Baptiste.

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

Re: [Cppunit-devel] TestSuiteBuilder & type info...

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

Baptiste Lepilleur wrote:
-8<--

> > They only thing we need (at least for the TestSuiteBuilder) is the fully
> > qualified class name of the Fixture. In case of the macros we already
> > got that.
>   You don't need to specify the full name in the macro. This would be hell when
> you need five lines of code to specify that name. Even if you do, you don't get
> the actual template parameter type.
>
>   For example:
>   template<class StringType>
>   class StringTest;
>
>   Test *testStringChar = StringTest<char>::suite();
>   Test *testStringWChar = StringTest<wchar_t>::suite();
>
>   In the macro you would get the same name for both suite, with RTTI you get
> StringTest<char> and StringTest<unsigned short> (with VC++), which is very
> useful when one fail but not the other.
>
>   This become important when you have 4 or 5 parameters which might themself be
> template (see this month expert column on generic programming in cuj for
> example: http://www.cuj.com/experts/1906/alexandr.htm?
> topic=experts&topic=experts )
>

OK, finally I start to understand what you mean! :-)
I've mostly been doing Java programming the last few years. No generics there,  so
I'm not too intimate with those and some other C++ features.
Thanks for the C++ Journal link. Interesting information, the author is pretty
sick bastard though: calling writing a dozen basic_string implementations 'fun'
:-D
I must be a C++ wimp ;-)

--8<--

>   I'm not saying that on windows you should only use RTTI. If you do a project
> that might be ported to Unix then you must not use RTTI. But RTTI provides
> useful functionnality when working with template and namespace and when you
> know that you will never go for another platform with a project you might as
> well use them.

I don't care what people do on their own projects: they should be free to keep any
platform dependencies they want.
My worry is that the more platform dependent features get into CppUnit the more
difficult it becomes to maintain:  people on other platforms cannot check whether
they break these features, more code than neccessary may come to depend on it,
etc. ,etc.

>
>   I've added a configuration to VC++ projects that do not use RTTI (that how I
> found out that AutoRegisterSuite did not work without RTTI).
>   It will be in this evening commit too.
>

OK, do what's necessary for the RTTI features. Now that I understand how it may be
useful, I would not want to keep excluding it from the project.

>
> > Do you mean removal of the 'registerFactory( TestFactory *factory )' or
> > the
> > whole class?
> > The registerFactory method is used in AutoRegisterSuite.h and
> > HostAppDoc, so
> > thes would be affected too. Please explain, or hack at will.
>   Euhh... I completly forgot it was used but I've done a workaround. see
> somewhere above.
>
> > g++ isn't as bad as the standard allows: the type_info name does not
> > change
> > between runs (and not even compilations AFAIK). But the mangled names
> > have
> > changed between 2.91, 2.95 and 2.96+.
>   OK. This is better than I though it was. Yet, not very usable for cppunit.
>

Indeed, it isn't. I'll see if I can get the reasoning behind from one of the g++
folks.

>
> > OK, as long as the name is only interpreted by humans, we can get away
> > with the
> > variance in the name. But once the name ends up being processed
> > automatically
> > somewhere, e.g. for multiplatform regression reporting, we're can run
> > into
> > trouble.
>   If I were to do multiplatform, I think I would name the test by hand to
> ensure that they have the same name. That is the cost of multiplatform, you
> must stick to the lowest common factor. The problem is often to find that
> lowest common factor. For cppunit, it is easily identified: do not use RTTI if
> you are doing multiplatform. We just have to stick it somewhere in the
> documentation (I'll put it in TestSuiteBuilder at the current time). But I
> would put it somewhere else. This fact is binded to the CU_USE_TYPEINFO macro,
> not TestSuiteBuilder. Any Suggestions on where to put that ?
>

With the TypeInfoHelper class?

Bastiaan


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

Re: [Cppunit-devel] templatized assertions

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

On Sun, May 20, 2001 at 11:44:44AM +0200, Baptiste Lepilleur wrote:

> >         static std::string toString( const T& x )
> >         {
> >             ostringstream ost;
> shouldn't is be std::ostringstream ost; ?

Yes, thanks.

>    Could you send the patch with the new assert/trait. I'd like to give it a
> try.

Here's what I'm currently using.


Index: src/cppunit/Makefile.am
===================================================================
RCS file: /cvsroot/cppunit/cppunit/src/cppunit/Makefile.am,v
retrieving revision 1.4
diff -u -b -B -r1.4 Makefile.am
--- src/cppunit/Makefile.am	2001/05/19 17:41:03	1.4
+++ src/cppunit/Makefile.am	2001/05/20 16:10:33
@@ -8,7 +8,6 @@
 lib_LTLIBRARIES = libcppunit.la
 
 libcppunit_la_SOURCES = \
-  TestAssert.cpp \
   TestCase.cpp \
   TestSuite.cpp \
   TestResult.cpp \
Index: include/cppunit/TestAssert.h
===================================================================
RCS file: /cvsroot/cppunit/cppunit/include/cppunit/TestAssert.h,v
retrieving revision 1.2
diff -u -b -B -r1.2 TestAssert.h
--- include/cppunit/TestAssert.h	2001/05/06 16:19:31	1.2
+++ include/cppunit/TestAssert.h	2001/05/20 16:10:33
@@ -2,10 +2,29 @@
 #define CPPUNIT_TESTASSERT_H
 
 #include <string>
+#include <sstream>
 #include <cppunit/Exception.h>
 
+
 namespace CppUnit {
 
+    template <class T>
+    struct assertion_traits 
+    {  
+	static bool equal( const T& x, const T& y )
+	{
+	    return x == y;
+	}
+
+	static std::string toString( const T& x )
+	{
+	    std::ostringstream ost;
+	    ost << x;
+	    return ost.str();
+	}
+    };
+
+
   /*! \brief This class represents
    */
   class TestAssert
@@ -17,24 +36,48 @@
       bool         condition, 
       std::string  conditionExpression = "",
       long         lineNumber = Exception::UNKNOWNLINENUMBER,
-      std::string  fileName = Exception::UNKNOWNFILENAME);
+      std::string  fileName = Exception::UNKNOWNFILENAME)
+	{
+	    if (!condition) 
+		throw Exception (conditionExpression, 
+				 lineNumber, 
+				 fileName); 
+	}
+
 
-    static void    assertEquals     (long         expected, 
-      long         actual,
+    template <class T>
+    static std::string         notEqualsMessage (const T& expected, 
+						 const T& actual)
+    {
+	return "expected: " + assertion_traits<T>::toString(expected)
+	     + " but was: " + assertion_traits<T>::toString(actual);
+    }
+
+
+    template <class T>
+    static void    assertEquals     (
+      const T&     expected,
+      const T&     actual,
       long         lineNumber = Exception::UNKNOWNLINENUMBER,
-      std::string  fileName = Exception::UNKNOWNFILENAME);
+      std::string  fileName = Exception::UNKNOWNFILENAME)
+	{
+	    assertImplementation( assertion_traits<T>::equal(expected,actual),
+				  notEqualsMessage(expected, actual), 
+				  lineNumber, 
+				  fileName); 
+	}
 
     static void    assertEquals     (double       expected, 
       double       actual, 
       double       delta, 
       long         lineNumber = Exception::UNKNOWNLINENUMBER,
-      std::string  fileName = Exception::UNKNOWNFILENAME);
-
-    static std::string         notEqualsMessage (long         expected, 
-      long         actual);
-
-    static std::string         notEqualsMessage (double       expected, 
-      double       actual);
+      std::string  fileName = Exception::UNKNOWNFILENAME)
+	{
+	    assertImplementation( fabs(expected - actual) <= delta,
+				  notEqualsMessage(expected, actual), 
+				  lineNumber, 
+				  fileName); 
+	}
   };
 
 
@@ -69,6 +112,15 @@
 
 /// Macro for primitive value comparisons
 #define assertLongsEqual(expected,actual)\
+(CppUnit::TestAssert::assertEquals ((expected),\
+        (actual),__LINE__,__FILE__))
+
+/// Generalized macro for primitive value comparisons
+/** Any type that implements operator== and operator<<
+ * can be compared.  A diagnostic is printed if the
+ * actual and expected values disagree.
+ */
+#define assertEqual(expected,actual)\
 (CppUnit::TestAssert::assertEquals ((expected),\
         (actual),__LINE__,__FILE__))
 

 

-- 
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] New TextTestRunner and hierarchy example update

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

On Sun, May 20, 2001 at 11:54:07AM +0200, Baptiste Lepilleur wrote:
> > Um.  I think you'd better revisit this change.
> >
> > I wasn't completely happy with the old output, and one of my "TODO"
> > items was to fix it and propose a patch.
> >
> > However, the new output is worse.  All I get is dots with no
> > terminating newline:
>    No, that's the way it's supposed to be (for me at least). It is also the
> way it was done in Michael Feather's version. To me it makes sense:
> 
>     The dots are a show progress. A 'F' is printed to show that a test has
> failed (equivalent to our progress becoming red). When all tests are run,
> you got a report showing what failed (error report need to be made more
> readable).

Yes, sure.  This is one option for output, I agree.  I think there ought to
be a newline after all the dots, that's all.  As it stands now, if all the
tests succeed, no further output is produced.

I also think that some folks (well, me anyway) may want a more verbose
output style.  I'm not suggesting that the default change.  Just that one
has an option.  I'll have a look and suggest a patch, maybe sometime this
week.
 

> > Seems okay, but someone broke "make distcheck" by removing a file from the
> > directory without updating the corresponding Makefile.am.
>    That would be me. I moved TypeInfoHolder.h from src to include. I knew
> this need to be updated when adding strange file (dsp/dsw), but I though it
> automatically retreived .cpp/.h (that would make sense to me).

Nope.  The Makefile.am files are the master record of the files required to
build the project.  They must be manually edited for all changes.


-- 
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] New TextTestRunner and hierarchy example update

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

> > Seems okay, but someone broke "make distcheck" by removing a file from
the
> > directory without updating the corresponding Makefile.am.
>    That would be me. I moved TypeInfoHolder.h from src to include. I knew
> this need to be updated when adding strange file (dsp/dsw), but I though
it
> automatically retreived .cpp/.h (that would make sense to me). I fixed it.
  Correction: Baastian fixed it before I could. Thanks Baastian.

    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] New TextTestRunner and hierarchy example update

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

> Um.  I think you'd better revisit this change.
>
> I wasn't completely happy with the old output, and one of my "TODO"
> items was to fix it and propose a patch.
>
> However, the new output is worse.  All I get is dots with no
> terminating newline:
   No, that's the way it's supposed to be (for me at least). It is also the
way it was done in Michael Feather's version. To me it makes sense:

    The dots are a show progress. A 'F' is printed to show that a test has
failed (equivalent to our progress becoming red). When all tests are run,
you got a report showing what failed (error report need to be made more
readable).

  Having test name and dot with new line would keep the screen scrolling.
This would be hard to use when you have more than a few tests.

  When we run test with the GUI test runner, we don't know which test is
running. On the other hand when a failure occurs, the full report is added
to the failure list. I guess we could dump the failure as soon it occured.
Though, I'm not sure that would be useful since failures would be spread
over many page of text which would keep scrolling as the other tests run.

  Also printing takes time, when you refactor and code test first, you run
the test every few seconds. You don't care which tests are run, you only
want to you if they run. You made sure that the test you added is run by
making it fails the first time.

  If that's not te way you to it, could you give your use case and the
output you'd like to have ?

> Whether to print test names or just dots should probably be made an
> option.  I liked having the names output.
  That could be done by giving the instance of the testresult to use to the
testrunner. But I'm not sure how to manage the lifecycle of the test result
(run() may be called more than once but testresult only support one run).
Suggestions ?

> Seems okay, but someone broke "make distcheck" by removing a file from the
> directory without updating the corresponding Makefile.am.
   That would be me. I moved TypeInfoHolder.h from src to include. I knew
this need to be updated when adding strange file (dsp/dsw), but I though it
automatically retreived .cpp/.h (that would make sense to me). I fixed it.

>
> -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] templatized assertions

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

> The traits class I'm using looks like the following, which can easily
> be specialized.
>
> namespace CppUnit {
>
>     template <class T>
>     struct assertion_traits
>

>         static bool equal( const T& x, const T& y )
>         {
>             return x == y;
>         }
>
>         static std::string toString( const T& x )
>         {
>             ostringstream ost;
shouldn't is be std::ostringstream ost; ?


>             ost << x;
>             return ost.str();
>         }
>     };
> }

   Could you send the patch with the new assert/trait. I'd like to give it a
try.

> I guess you could use a "traits namespace", instead.  I'm not
> well-versed enough to know why classes are used over namespaces for
> traits.  Maybe its historical?  Or maybe it has something to do with
> being able to partially specialize a class template?  I discovered the

  I think it has to do with the fact you can specify a traits as a template
parameter type. I don't think you can to that with a namespace. This is a
very powerful idiom. See this month online expert column by Andrei
Alexandrescu on CUJ for pointer.

> hard way that GCC does not allow default template parameters in
> templated functions, while it does allow them for templated classes.
> This leads me to suspect that templated classes are better supported
> than templated functions, and for this reason the former are used
 > for traits.
  That's likely true. STL uses trait specialization, but I'm not sure it
uses function specialization. Let's stick to traits for now, I don't think
you need to override only one function that often.

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] New TextTestRunner and hierarchy example update

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

On Sat, May 19, 2001 at 01:44:50PM +0200, Baptiste Lepilleur wrote:
> I've added a TextTestRunner and updated the hierarchy example to use it.
> 
> Name of the test that was running has been removed from TextTestResult since
> it was obfuscating the output.

Um.  I think you'd better revisit this change.  

I wasn't completely happy with the old output, and one of my "TODO"
items was to fix it and propose a patch.

However, the new output is worse.  All I get is dots with no
terminating newline:

	steve@riemann{intersection}./test_segment 
	...steve@riemann{intersection}

Very ugly.  

Whether to print test names or just dots should probably be made an
option.  I liked having the names output.

 
> Let me know how that works on Unix.

Seems okay, but someone broke "make distcheck" by removing a file from the
directory without updating the corresponding Makefile.am.

-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

Re: [Cppunit-devel] templatized assertions

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

Hi Baptiste,

First, thanks _so_ much for suggesting that an equality function be
part of the assertion traits class.  That's precisely what I needed
yesterday!  The brilliant point is that both equality and the string
representation for a type can be different for assertions than it is
for other code.

The traits class I'm using looks like the following, which can easily
be specialized.

namespace CppUnit {

    template <class T>
    struct assertion_traits 
    {  
        static bool equal( const T& x, const T& y )
        {
            return x == y;
        }

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



On Sat, May 19, 2001 at 02:38:07PM +0200, Baptiste Lepilleur wrote:
> 
> 
> > On Wed, May 16, 2001 at 09:28:06PM +0200, Baptiste Lepilleur wrote:
> > > I would use a trait to add the object to the stream. The trait generic
> > > implementation would use '<<', but could be specialized when needed.
> >
> > That sounds like a reasonable idea.  I'm not terribly experienced in
> > traits; what would be a good name for the function?  Some of CppUnit
> > already uses "toString", which seems reasonable enough, yes?
>
>  How about using specialized template function:

  [...]

> I like that one because it solves the naming problem and you can change only
> the behavior you really need to change.

That sounds like you want to do away with wrapping the functions in a
common traits class.  I see your point about being able to override
each function individually.  I'm not convinced that this outweighs the
value of wrapping up the functions in a common name space, as a traits
class does.  

I guess you could use a "traits namespace", instead.  I'm not
well-versed enough to know why classes are used over namespaces for
traits.  Maybe its historical?  Or maybe it has something to do with
being able to partially specialize a class template?  I discovered the
hard way that GCC does not allow default template parameters in
templated functions, while it does allow them for templated classes.
This leads me to suspect that templated classes are better supported
than templated functions, and for this reason the former are used
for traits.

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