cppunit-devel — CppUnit Developer Mailing List

Re: [Cppunit-devel] templatized assertions

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

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

template<class Type>
std::string
toString( Type &object )
{
  std::ostringstream stream;
  stream << object;
  return stream.str();
}

template<class Type>
bool
equalsTo( Type &object1, Type &object2 )
{
  return object1 == object2;
}

// Example of specializations:

struct MyObject
{
  std::string print()
  {
    return "<MyObject>";
  }
};

template<>
std::string
toString<MyObject>( MyObject &object )
{
  return object.print();
}

template<>
bool
equalsTo<MyObject>( MyObject &object1, MyObject &object2 )
{
  return &object1 == &object2;
}

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

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

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

You forgot one thing:

Previously the standard library method ' const char* =
std::exception::what()' was used, but as you can see it can only return =
a single byte charactar string, not unicode (a designflaw if you ask =
me). I have therefore added a method '_tstring Exception::uwhat()', to =
return exception strings in unicode.

Enjoy.

    Michael Arnoldus

----- Original Message -----=20
From: "Baptiste Lepilleur" <bl...@cl...>
To: "Cpp Unit Develpment Mailing List" =
<cpp...@li...>
Sent: Friday, May 18, 2001 11:33 PM
Subject: [Cppunit-devel] Unicode


> Michael Arnoldus gracefuly sent me a unicode version of CppUnitW 1.2.
>=20
> The change required to add unicode support in cppunit are:
>=20
> * having alias to std::string or std::wstring depending on weither we =
are
> compiling for unicode or not. This also apply to ostrstream, cerr, and =
cout.
>=20
> Michael did it that as follow:
>=20
> #ifdef _UNICODE
> #define _tstring wstring
> #else
> #define _tstring string
> #endif
>=20
> This could probably be done using typedef and creating string in =
CppUnit
> namespace too:
>=20
> #ifdef _UNICODE
> typedef std::wstring string
> #else
> typedef std::string string
> #endif
>=20
> * having a macro _T which make the specified string unicode when =
needed:
>   std::_tstring( _T( "Unknown" ) )
>=20
> * 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)
>=20
> * adding new configuration to projects setting for VC++
>=20
> (Michael let me know if I forgot something)
>=20
> Note for Unix developper:
> The _t thingy is a win32 idiom. We have a tchar.h header which =
provides all
> string function with such a prefix, aliasing to either single byte =
character
> string or unicode character string function depending on _UNICODE =
symbol.
>=20
> Is there such an idiom for Unix ?
>=20
> Here is the "Unicode TODO" list that I can see for now:
> - make a new header file which contains all stuffs relating to unicode
> (macros, typedef...)
> - replace character dependent object used in cppunit with those =
defined in
> the previous header
> - add the ustring function.
>=20
> I'm can do all those stuffs but we need to define the specific (header =
file
> name, define/typedef, alias name, _T name...).
>=20
> 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] New TextTestRunner and hierarchy example update

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

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.

I've also merged Steve M. Robbins patch to replace assertImplementation with
assert in hierarchy example.

Let me know how that works on Unix.

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] missing std:: ?

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

    I stumbled on  some code yesterday:

void 
TestCase::run (TestResult *result)
{
[...]  
  try {
    runTest ();
  }
[...]
  catch (exception& e) {
    result->addError (this, new Exception (e.what ()));
  }

=> shouldn't that be std::exception ?

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

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

Michael Arnoldus gracefuly sent me a unicode version of CppUnitW 1.2.

The change required to add unicode support in cppunit are:

* having alias to std::string or std::wstring depending on weither we are
compiling for unicode or not. This also apply to ostrstream, cerr, and cout.

Michael did it that as follow:

#ifdef _UNICODE
#define _tstring wstring
#else
#define _tstring string
#endif

This could probably be done using typedef and creating string in CppUnit
namespace too:

#ifdef _UNICODE
typedef std::wstring string
#else
typedef std::string string
#endif

* having a macro _T which make the specified string unicode when needed:
  std::_tstring( _T( "Unknown" ) )

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

* adding new configuration to projects setting for VC++

(Michael let me know if I forgot something)

Note for Unix developper:
The _t thingy is a win32 idiom. We have a tchar.h header which provides all
string function with such a prefix, aliasing to either single byte character
string or unicode character string function depending on _UNICODE symbol.

Is there such an idiom for Unix ?

Here is the "Unicode TODO" list that I can see for now:
- make a new header file which contains all stuffs relating to unicode
(macros, typedef...)
- replace character dependent object used in cppunit with those defined in
the previous header
- add the ustring function.

I'm can do all those stuffs but we need to define the specific (header file
name, define/typedef, alias name, _T name...).

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] TestSuiteBuilder & type info...

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

>   I made change to fix the whole stuff yesterday evening. It doesn't break
any
> code, and TestSuite is not impacted.
>   I modified the macro so it use RTTI if allowed, and use the macro
parameter
> name otherwise. I also fixed TestFactoryRegistry so it doesn't use RTTI
anymore
> (dummy name are generated instead).
>   I'll commit the whole thing this evening.
  It's done.

  CU_TEST_SUITE_REGISTRATION and AutoRegisterSuite can now be used without
RTTI.

 Notes that USE_TYPEINFO have been changed to CU_USE_TYPEINFO.

  A configuration have been added to VC++ project to compile without
typeinfo.

  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] fixup examples/hierarchy

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

Hi,

During the exchange yesterday, it came out that the example code
is using assertImplementation() for no discernable reason.
Here's a quick patch that changes to the cleaner assert() macro.

-S


Index: examples/hierarchy/BoardGameTest.h
===================================================================
RCS file: /cvsroot/cppunit/cppunit/examples/hierarchy/BoardGameTest.h,v
retrieving revision 1.8
diff -u -b -B -r1.8 BoardGameTest.h
--- examples/hierarchy/BoardGameTest.h	2001/05/06 20:04:02	1.8
+++ examples/hierarchy/BoardGameTest.h	2001/05/18 14:23:25
@@ -42,13 +42,13 @@
     
     void testReset () 
     { 
-      assertImplementation (m_game->reset (),"m_game->reset ()",__LINE__,__FILE__); 
+      assert( m_game->reset() );
     }
 
     void testResetShouldFail () 
     { 
       std::cout << "The following test fails, this is intended:" << std::endl;
-      assertImplementation (!m_game->reset (),"!m_game->reset ()",__LINE__,__FILE__); 
+      assert( !m_game->reset() );
     }
     
 };


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

> Hmm, the macros are itended to be used, aren't they? Else I see no
> reason to
> include them in the project.
  The macro have been design for 2 (3) things:
  - make first contact with cppunit easier. You don't have to understand the 
whole framework (notes that has drawback, you don't get to know the framework 
and may stick to macro instead of exploring the framework possibilities).
  - make it easy to write basic test.
  - (unoffical: easy conversion of my old unit test writen with my old unit 
testing framework).

  There is drawback though: you can only do what the macro have been designed 
to do: you can not use decorator, orthodox... You lose cppunit awesome 
flexibility.

> >     3) you can't extract namespace that way
> 
> 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 )

> I thought I mentioned it here last week, but obviously I didn't. Sorry
> for
> that, I was on a very thight time schedule: can't do CppUnit related
> stuff at
> work at the moment and had to study for a computer ethics exam in the
> evening.
  I understand that, I have a hard jungling between projects and finding time 
for them too.

> About 'why not in TestSuiteBuilder': same reason as for TestSuite. The
> added
> value is minimal: it's trivial to create the name outside the
> TestSuiteBuilder
> class,  either with your RTTI  TypeInfoHelper or with a hand-coded
> string.
  See my remarks above. 
  I made change to fix the whole stuff yesterday evening. It doesn't break any 
code, and TestSuite is not impacted.
  I modified the macro so it use RTTI if allowed, and use the macro parameter 
name otherwise. I also fixed TestFactoryRegistry so it doesn't use RTTI anymore 
(dummy name are generated instead).
  I'll commit the whole thing this evening.

> I you do want to use RTTI in other places, please show why, where and
> how! I'm
> not against RTTI per se, but I see little use for it so far.
  See notes about template. It also works for namespace.

> Yes, subclassing may not be ideal and not necessarily the best solution,
> but I
> think having different interfaces for the same class on different
> platforms is
> worse: I really want to avoid that people write extensions to CppUnit
> that may
> be useful on all platforms in a non portable way simply because on their
> platform CppUnit has a different interface.
  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'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.

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


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

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

> > No, it breaks the interface published in CppUnitW 1.2. The change already
> > had been made before the release of 1.5.5. I don't know whether that
> > increases or decreases your horror.
> > I'm sorry if I haven't made clear that I made these changes in preparation
> > of the 1.5.5 release. Now that you've got CVS working, missing updates
> > should be less likely.
>     Indeed, it seems that when I download the 1.5.5 release on sourceforge,
> the overwrite somehow failed and I was left with the old version you gave me
> for validation.
>
> > Whether you need RTTI depends on how/where you the need the name. For
> > example if you use your CU_TEST_SUITE HelperMacro, the Fixture name is
> > already available as the macro parameter.
>     1) macro are only there to make it easier to get started. I don't use
> CU_TEST_SUITE other than in old code (which used to be based on my old test
> framework and relied on macro to simulate reflection).

Hmm, the macros are itended to be used, aren't they? Else I see no reason to
include them in the project.

>
>     2) you can not extract template parameters that way. Trying to extract
> the name of the template parameter can be hell (at the top of my head, I'm
> thinging of traits)
>     3) you can't extract namespace that way

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.
For direct TestSuiteBuilder usage it's a question of giving it the name
yourself, not a big deal is it?

>
> > Portability is an issue: CppUnit is intented to be a cross platform
> library,
> > so the core feature set should be identical everywhere. Also the
> development
> > of CppUnit becomes messy if platform dependent code is scattered across
> core
> > classes. That's why I did not want RTTI stuff in TestSuite.
>     Ok for the removal from TestSuite, but why haven't you move it to
> TestSuiteBuilder ?
>     Why wasn't it discussed on this list ?
>

I thought I mentioned it here last week, but obviously I didn't. Sorry for
that, I was on a very thight time schedule: can't do CppUnit related stuff at
work at the moment and had to study for a computer ethics exam in the evening.
I'll try to be more communicative in the future.
About 'why not in TestSuiteBuilder': same reason as for TestSuite. The added
value is minimal: it's trivial to create the name outside the TestSuiteBuilder
class,  either with your RTTI  TypeInfoHelper or with a hand-coded string.

>
> > especially since the HelperMacros do not actually need the RTTI support.
>     Wrong, see problem with template and namespace above.

Could you elaborate a bit more about this problem? I don't see it. All I see is
just a simple name string for TestSuites.
I you do want to use RTTI in other places, please show why, where and how! I'm
not against RTTI per se, but I see little use for it so far.

>
>     Are you invocating the use of macro ;-) ?
>
> > For an RTTI supporting TestSuiteBuilder, I suggest subclassing it to add
> the
> > RTTI based constructor.
>     This would get messy, if somebody subclass TestSuiteBuilder to add some
> functionnality, it would make RTTI unusable. I don't see what's wrong by
> adding a constructor that is not available everywhere. Subclassing would be
> applying the refactoring "Introduce Local Extension" within the libary!!!
> Refer to the refactoring catalog, and you'll see there are many drawback
> with this (like the one I gave).
>

Yes, subclassing may not be ideal and not necessarily the best solution, but I
think having different interfaces for the same class on different platforms is
worse: I really want to avoid that people write extensions to CppUnit that may
be useful on all platforms in a non portable way simply because on their
platform CppUnit has a different interface.

>
> > In any case the TestSuiteBuilder is a smaller issue because it's not a
> core
> > class, and it's only a header file: no RTTI dependent code would have been
> > compiled in the CppUnit library either way.
> > That leaves the TestFactoryRegistry class, which still has the
> USE_TYPEINFO
> > #ifdef. I like to solve the issue somehow there too, before 1.5.6.
> > Suggestions are welcome!
>     This one could be removed since it is unused at the time, and I'm unsure
> of its use.
>

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.


>
> > BTW, g++ isn't broken, the C++ standard is, because it does not specify
> > exactly what type_info::name() should return. The g++ people have simply
> > made a (for this purpose) not so useful choice of returning the mangled
> > name.
>     Sorry, I misused "proper". What I intended was more akin to "useful". I
> don't see any use for a name that can change between run and is not human
> readable.
>

The mangled name could be useful for debugging purposes. But like you, I'd
rather have a name() method that would return the fully qualified unmangled
name and and a raw_name() method that returns the mangled name, like MSVC++
does.
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+.

>
> > In fact, the next release of MSVC++ may return something completely
> > different from the current release as well. The underspecification of the
> > name() method, makes me suspicious of using it.
>     Well, as long as they keep it human readable there will be no problem. I
> don't think this will be a problem. Even if "class" is not prepend to class
> and template name, it will just be left. I removed it to shorten the name.
>

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.

A+

Bastiaan

Re: [Cppunit-devel] build fixes

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

"Steve M. Robbins" wrote:

> Hi,
>
> I've corrected a few places where files need to be referenced using
> $(srcdir) or $(top_srcdir).  After applying this, you ought to be able
> to build cppunit with builddir != srcdir.  That is useful in itself,
> but the bigger win is that "make distcheck" now works.
>

Thanks! Fixing distcheck was on my todo list. Now for some useful tests
besides building the hierarchy example...

Bastiaan


>
> Cheers,
> -Steve
>
> Here are the ChangeLog entries.  The diff is attached.
>
> 2001-05-17  Steve M. Robbins  <st...@ny...>
>
>         * Makefile.am (dist-hook): Copy files relative to $(top_srcdir).
>
>         * doc/Makefile.am: Generated doc files depend on Doxyfile.
>
>         * doc/Doxyfile.in: Use autoconf substitutions in file names.
>
>         * examples/hierarchy/Makefile.am (check_PROGRAMS): Build hierarchy
>         with "make check", not "make all".
>
>         * examples/hierarchy/Makefile.am (INCLUDES):
>         * src/cppunit/Makefile.am (INCLUDES): Search in
>         $(top_srcdir)/include.
>
> --
> 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
>
>   ------------------------------------------------------------------------
>
>    diffName: diff
>        Type: Plain Text (text/plain)

Re: [Cppunit-devel] templatized assertions

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

On Thu, May 17, 2001 at 09:45:03PM +0200, Baptiste Lepilleur wrote:
> > > If you look at the source you have:
> > > /** A set of macros which allow us to get the line number
> > >  * and file name at the point of an error.
> > >  * Just goes to show that preprocessors do have some
> > >  * redeeming qualities.
> > >  */
> > > #define CPPUNIT_SOURCEANNOTATION
> > >
> > > #ifdef CPPUNIT_SOURCEANNOTATION
> > > ...
> > >
> > > Which means if you removed the define, you must use the implementation
> > > (TestAssert).
> >
> > Read a bit further; there is an #else clause!  This symbol is used to
> > choose between two different implementations of the assert macro.  In
> > both cases, you have a macro named "assert".
> 
> Sorry. I wrote this from memory and it seems it's pretty messed up (that
> what you get when you're playing with 3 differents versions of cppunit
> ;-(. )

I understand.  I think you're still suffering from source code overload,
however.

> Is CPPUNIT_SOURCEANNOTATION really required ? The only reason I can see for
> it would be that some weird compiler does not support the __FILE__ &
> __LINE__ macros. Have anobody hear of something like that ?

No, but then __FILE__ and __LINE__ is not the difference between the two
assert() macros.

#ifdef CPPUNIT_SOURCEANNOTATION

    #undef assert
    #define assert(condition)\
    (CppUnit::TestAssert::assertImplementation ((condition),(#condition),\
        __LINE__, __FILE__))

#else

    #undef assert
    #define assert(condition)\
    (CppUnit::TestAssert::assertImplementation ((condition),"",\
        __LINE__, __FILE__))

#endif

The difference is the use of (#condition) in the first.  That seems to
make "condition" into a string.  

It's the first time I've seen this, so it wouldn't surprise me that
some preprocessors don't understand it.  On the other hand, it
wouldn't surprise me to learn this has been in the C standard for 10
years.  I try to use the preprocessor as little as possible.  :-/


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

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

Hi,

I've corrected a few places where files need to be referenced using
$(srcdir) or $(top_srcdir).  After applying this, you ought to be able
to build cppunit with builddir != srcdir.  That is useful in itself,
but the bigger win is that "make distcheck" now works.

Cheers,
-Steve

Here are the ChangeLog entries.  The diff is attached.

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

	* Makefile.am (dist-hook): Copy files relative to $(top_srcdir).

	* doc/Makefile.am: Generated doc files depend on Doxyfile.

	* doc/Doxyfile.in: Use autoconf substitutions in file names.

	* examples/hierarchy/Makefile.am (check_PROGRAMS): Build hierarchy
	with "make check", not "make all".

	* examples/hierarchy/Makefile.am (INCLUDES): 
	* src/cppunit/Makefile.am (INCLUDES): Search in
	$(top_srcdir)/include.



-- 
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] Release 1.5.5 not announced in cpp--announce

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

Baptiste Lepilleur wrote:

>   The release 1.5.5 should be announced in the announced mailing list (even if
> late), otherwise people will never subcribe, and if some did subscribe, they
> will never know that 1.5.5 was subcribed.
>
>   How is this done ? My guess is that only admins can post to that list. I am
> right ?
>

I suspect everyone can post to this list. I don't have admin access to it, so I
can't check.
But I don't see much use for an announce mailing list: the 'monitor file relase'
already includes the announce functionality and is easier to use.
Likewise I suspect the cvslog mailing list won't see much use either.
So to avoid confusion I propose to delete them alltogether. If anyone has
objections, please speak up or I'll disable them coming weekend.

Bastiaan


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

Re: [Cppunit-devel] ignore files

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

"Steve M. Robbins" wrote:

> Hi,
>
> As I mentioned yesterday, I find .cvsignore files very helpful
> when trying to figure out what has changed between the repository
> and my files.
>

They are.

>
> I sat down and created some for cppunit, and here they are.
>

OK, thanks! They have been merged.

Cheers,

Bastiaan

Re: [Cppunit-devel] templatized assertions

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

> > If you look at the source you have:
> > /** A set of macros which allow us to get the line number
> >  * and file name at the point of an error.
> >  * Just goes to show that preprocessors do have some
> >  * redeeming qualities.
> >  */
> > #define CPPUNIT_SOURCEANNOTATION
> >
> > #ifdef CPPUNIT_SOURCEANNOTATION
> > ...
> >
> > Which means if you removed the define, you must use the implementation
> > (TestAssert).
>
> Read a bit further; there is an #else clause!  This symbol is used to
> choose between two different implementations of the assert macro.  In
> both cases, you have a macro named "assert".

Sorry. I wrote this from memory and it seems it's pretty messed up (that
what you get when you're playing with 3 differents versions of cppunit
;-(. )

Is CPPUNIT_SOURCEANNOTATION really required ? The only reason I can see for
it would be that some weird compiler does not support the __FILE__ &
__LINE__ macros. Have anobody hear of something like that ?

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

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

On Thu, May 17, 2001 at 06:35:02PM +0200, Baptiste Lepilleur wrote:
> Quoting "Steve M. Robbins" <ste...@vi...>:
 
> > ... unless folks are using the class functions CppUnit::TestAssert::
> > TestImplementation(), etc directly.  Do you?  What is the advantage of
> > doing that?
>   See Dolores Scott mail. I only have very few idea why someone would not rely 
> on the assert:
>   1) Somewhere there are some include of C assert, which override our assert 
> macro... I'm still trying to find a work around that one. Suggestions are 
> welcome.

True.  The only fix that comes to mind is for CppUnit to use a
different macro name.


> > I don't understand what you mean by "disabled the assert macro".  I
> > don't see a
> > way for doing that.  Are you referring to folks directly using the
> > TestAssert
> > member functions?
> 
> If you look at the source you have:
> /** A set of macros which allow us to get the line number
>  * and file name at the point of an error.
>  * Just goes to show that preprocessors do have some
>  * redeeming qualities.
>  */
> #define CPPUNIT_SOURCEANNOTATION
>   
> #ifdef CPPUNIT_SOURCEANNOTATION
> ...
> 
> Which means if you removed the define, you must use the implementation 
> (TestAssert).

Read a bit further; there is an #else clause!  This symbol is used to
choose between two different implementations of the assert macro.  In
both cases, you have a macro named "assert".



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

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

Quoting "Steve M. Robbins" <ste...@vi...>:

> Okay.  I have defined a templated class named AssertionTraits, with 
> exactly one member: toString.  Using a traits class for just one thing
> seems like overkill to me.  What other things do you suppose might go
> in there?  Is there a better name than AssertionTraits?
  The == operator seems like something that could be in the traits to.
  I'm not very good at naming stuff in english, but I would prefer a name that 
show that its not about assertion (the assertion is not done there), but 
converting the object to a string, and testing object for equality.

> That was my thinking: the assert macros are the interface, as far as I
> know (but remember that I only started using CppUnit this week!), so
> what they use as a back-end is irrelevant.  Global functions in a
> TestAssert namespace should do just as well.
  My though too.

> ... unless folks are using the class functions CppUnit::TestAssert::
> TestImplementation(), etc directly.  Do you?  What is the advantage of
> doing that?
  See Dolores Scott mail. I only have very few idea why someone would not rely 
on the assert:
  1) Somewhere there are some include of C assert, which override our assert 
macro... I'm still trying to find a work around that one. Suggestions are 
welcome.
  2) Don't want to use macro despite their usefulness
  3) Copied the example (which for unknown reason use assertImplementation). 
That one can be twisted around by implementing it in the TestCase class, and 
marking it as "deprecated" for later removal.

  I use macro because they provide location information. I'm still dreaming of 
having a stack trace ;-) 

> I discovered an annoyance with the current names.  As I mentioned the
> other
> day, I'd like to have a generic "assert a ==  b" macro.  I tentatively
> called it assertEqual.  The definition is as follows:
> 
> 	#define assertEqual(expected,actual)\
> 	(CppUnit::TestAssert::assertEquals ((expected),\
> 	        (actual),__LINE__,__FILE__))
> 
> unfortunately, the name is too close to TestAssert::assertEquals, which
> can also take two parameters (the last two have default values).  This
> makes it way too easy (I've already done it once) to use
> assertEquals(x,y)
> in the test case, and then wonder why the failure shows up at "unknown
> line".
  I often also have the problem with the assertLongEqual which I write 
assertLongEquals. Fortunately it ends with compiler error...

> 
> If nobody is using the back-end functions, I'd solve this by just
> renaming
> them.  Then, using assertEquals() would be a compile-time error.
> 
> Of course, the other way to solve it is to pick a sufficiently
> different
> name for the new macro.  Suggestions welcome.
  I would rather remove the existing assertEquals method which have "the" 
intuitive name. I don't like twisting around when its not needed.

> I don't understand what you mean by "disabled the assert macro".  I
> don't see a
> way for doing that.  Are you referring to folks directly using the
> TestAssert
> member functions?

If you look at the source you have:
/** A set of macros which allow us to get the line number
 * and file name at the point of an error.
 * Just goes to show that preprocessors do have some
 * redeeming qualities.
 */
#define CPPUNIT_SOURCEANNOTATION
  
#ifdef CPPUNIT_SOURCEANNOTATION
...

Which means if you removed the define, you must use the implementation 
(TestAssert).


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

Re: [Cppunit-devel] templatized assertions

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

> 
> >   Removing inheritance would require people to explicitly use the
> namespace for
> > assertion if they disabled the assert macro. Anybody see a problem
> with
> that ?
> 
> Only that it breaks existing test code.

  Are you refering to code you have implemented or code other people may have 
implemented ?
  If you used TestAssert, I'd like to know why you did not use the assert macro 
which provides more information. 

  Given that the loss of information make it harder not to have to run the 
debugger, I'm really curious to know why someone would use TestAssert instead 
of the helper macro.

  Baptiste. 

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

Re: [Cppunit-devel] templatized assertions

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

On Thu, May 17, 2001 at 02:16:20PM +0200, Baptiste Lepilleur wrote:
> Quoting "Steve M. Robbins" <ste...@vi...>:

> > 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?
>   It looks good to me.

Okay.  I have defined a templated class named AssertionTraits, with 
exactly one member: toString.  Using a traits class for just one thing
seems like overkill to me.  What other things do you suppose might go
in there?  Is there a better name than AssertionTraits?

 
> > Actually: why does TestAssert need to be a class at all?  There are no
> > data members, so why not just make it a namespace with a bunch of
> > templatized functions?
>   The idea was to inherit that class when you wanted to use assertion. But this 
> is of no use since we use macro to capture source file & line number and those 
> macro are global.

That was my thinking: the assert macros are the interface, as far as I
know (but remember that I only started using CppUnit this week!), so
what they use as a back-end is irrelevant.  Global functions in a
TestAssert namespace should do just as well.

... unless folks are using the class functions CppUnit::TestAssert::
TestImplementation(), etc directly.  Do you?  What is the advantage of
doing that?

I discovered an annoyance with the current names.  As I mentioned the other
day, I'd like to have a generic "assert a ==  b" macro.  I tentatively
called it assertEqual.  The definition is as follows:

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

unfortunately, the name is too close to TestAssert::assertEquals, which
can also take two parameters (the last two have default values).  This
makes it way too easy (I've already done it once) to use assertEquals(x,y)
in the test case, and then wonder why the failure shows up at "unknown line".

If nobody is using the back-end functions, I'd solve this by just renaming
them.  Then, using assertEquals() would be a compile-time error.

Of course, the other way to solve it is to pick a sufficiently different
name for the new macro.  Suggestions welcome.

 
>   Using namespace should indeed solve the template member problem.
>   I can see the following impact:
>   - remove inheritance of TestAssert in TestCase
>   - update the sample to use assert macro instead of assertImplementation (I 
> wonder why it's doing that anyway)
> 
>   Removing inheritance would require people to explicitly use the namespace for 
> assertion if they disabled the assert macro. Anybody see a problem with that ?

I don't understand what you mean by "disabled the assert macro".  I don't see a
way for doing that.  Are you referring to folks directly using the TestAssert
member functions?
 
-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

[Dolores S. <ds...@sy...>]

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



>   Removing inheritance would require people to explicitly use the
namespace for
> assertion if they disabled the assert macro. Anybody see a problem with
that ?

Only that it breaks existing test code.

Dolores Scott

Re: [Cppunit-devel] templatized assertions

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

Quoting "Steve M. Robbins" <ste...@vi...>:

> 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?
  It looks good to me.

> > Also, since it is a template member, if should be protected with a
> define.
> > VC++ 5.0 (and many other compiler I guess) does not support template
> member
> > for example (though it a static member so I'm not sure).
> 
> I'm not very knowledgable about the state of support for various
> features
> of the language.  What is the workaround for compilers that don't
> support
> template static members?
  I don't really know, but I can think of a few dirty things (make it a 
templatized function which take the class instance as parameter).
  The clean way would probably to add the "expected" template instantiation as 
method (such as the current assertEquals).

> 
> Actually: why does TestAssert need to be a class at all?  There are no
> data members, so why not just make it a namespace with a bunch of
> templatized functions?
  The idea was to inherit that class when you wanted to use assertion. But this 
is of no use since we use macro to capture source file & line number and those 
macro are global.

  Using namespace should indeed solve the template member problem.
  I can see the following impact:
  - remove inheritance of TestAssert in TestCase
  - update the sample to use assert macro instead of assertImplementation (I 
wonder why it's doing that anyway)

  Removing inheritance would require people to explicitly use the namespace for 
assertion if they disabled the assert macro. Anybody see a problem with that ?

  Baptiste.

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

[Cppunit-devel] Release 1.5.5 not announced in cpp--announce

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

  The release 1.5.5 should be announced in the announced mailing list (even if 
late), otherwise people will never subcribe, and if some did subscribe, they 
will never know that 1.5.5 was subcribed.

  How is this done ? My guess is that only admins can post to that list. I am 
right ?

  Baptiste.

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

[Cppunit-devel] ignore files

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

Hi,

As I mentioned yesterday, I find .cvsignore files very helpful
when trying to figure out what has changed between the repository
and my files.

I sat down and created some for cppunit, and here they are.

Cheers,
-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...>]

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?

 
> Also, since it is a template member, if should be protected with a define.
> VC++ 5.0 (and many other compiler I guess) does not support template member
> for example (though it a static member so I'm not sure).

I'm not very knowledgable about the state of support for various features
of the language.  What is the workaround for compilers that don't support
template static members?

Actually: why does TestAssert need to be a class at all?  There are no
data members, so why not just make it a namespace with a bunch of
templatized functions?

-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

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

I would use a trait to add the object to the stream. The trait generic
implementation would use '<<', but could be specialized when needed.

Also, since it is a template member, if should be protected with a define.
VC++ 5.0 (and many other compiler I guess) does not support template member
for example (though it a static member so I'm not sure).

In JUnit, there is also a assertion of the form
assert( bool, message )...


----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: <cpp...@li...>
Sent: Tuesday, May 15, 2001 10:43 PM
Subject: [Cppunit-devel] templatized assertions


> Hello,
>
> Using 1.5.5, I can see two flavours of assertions:
>
> assert( boolean )
> and assertDoublesEqual( double, double ) [ also assertLongsEqual() ]
>
> The second form is potentially very useful, since it allows the
> diagnostic message to say "expected X, got Y".  I'd like to extend
> this form of assertion to arbitrary types.
>
> To this end, I've added templatized assertEquals() and
> notEqualsMessage() member functions to class TestAssert, and a new
> assertion macro "assertEqual(x,y)".  The assertion will work on any
> type that has operator=() and operator<<().
>
> The patch below does work.  Before I go further down this road and
> submit a full patch with doc changes, and the whole 9 yards, I thought
> I'd check to see whether you folks see a problem with this approach.
> Perhaps this approach has been previously considered and discarded?
>
> Comments?
> -Steve
>
>
>
> 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/15 20:20:50
> @@ -2,6 +2,7 @@
>  #define CPPUNIT_TESTASSERT_H
>
>  #include <string>
> +#include <sstream>
>  #include <cppunit/Exception.h>
>
>  namespace CppUnit {
> @@ -19,22 +20,34 @@
>        long         lineNumber = Exception::UNKNOWNLINENUMBER,
>        std::string  fileName = Exception::UNKNOWNFILENAME);
>
> -    static void    assertEquals     (long         expected,
> -      long         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)
> + {
> +     if (expected != actual)
> + assertImplementation (false, 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);
> +    template <class T>
> +    static std::string         notEqualsMessage (const T& expected,
> + const T& actual)
> + {
> +     ostringstream ost;
> +     ost << "expected: " << expected
> + << " but was: " << actual;
> +     return ost.str();
> + }
>
> -    static std::string         notEqualsMessage (double       expected,
> -      double       actual);
>    };
>
>
> @@ -69,6 +82,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
>
>
> _______________________________________________
> Cppunit-devel mailing list
> Cpp...@li...
> http://lists.sourceforge.net/lists/listinfo/cppunit-devel
>