Thread: [Cppunit-devel] macros and templates
Brought to you by:
blep
Menu
▾
▴
cppunit-devel
|
From: Steve M. R. <ste...@vi...> - 2001-06-02 23:49:55
|
I've added the generic TestAssert::assertEquals() method, along with the new macros CPPUNIT_ASSERT, CPPUNIT_ASSERT_EQUAL, and CPPUNIT_ASSERT_DOUBLES_EQUAL. The old naked assert and friends are available by editing <cppunit/config.h>. At the moment, the assertion_traits class requires string streams, which does not exist in GCC before version 2.95.3. If you have any bright ideas about workarounds for missing <sstream>, I'm all ears. All the old CU_* got renamed to CPPUNIT_*. I did this with a global string replace. This changes some of the MSVC files. I hope they still work. Let me know. -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 |
|
From: Bastiaan B. <bas...@li...> - 2001-06-05 00:16:00
|
"Steve M. Robbins" wrote:
> I've added the generic TestAssert::assertEquals() method,
> along with the new macros CPPUNIT_ASSERT, CPPUNIT_ASSERT_EQUAL,
> and CPPUNIT_ASSERT_DOUBLES_EQUAL. The old naked assert and
> friends are available by editing <cppunit/config.h>.
>
> At the moment, the assertion_traits class requires string streams,
> which does not exist in GCC before version 2.95.3. If you have any
> bright ideas about workarounds for missing <sstream>, I'm all ears.
In the log4cpp library we encountered the same problem. There we use but
ostringstream, I guess in CppUnit that's all we need too.
The current workaround is that we have an OstringStream class within the
log4cpp namespace which is derived from either ostringstream (for g++ >=
2.95.3) or ostrstream (for g++ < 2.95.3), based on the HAVE_SSTREAM
macro.
The ostrstream version overrides the str() method in the following way:
std::string OstringStream::str() {
(*this) << '\0';
std::string msg(ostrstream::str());
ostrstream::freeze(false); //unfreeze stream
return msg;
}
Yes, this means the str() method modifies the strstream, but because we
don't call str() more than one time we can get away with it :-)
The choice for a separate OstringStream class has probably more to do
with the fact that it also aggregates a vform() method rather than with
the missing sstream.
Alternatively we could leave the ostringstream using code as is and add
an ostringstream class based on the above to namespace 'std' to provide
a workaround.
Neither option is really elegant, if someone has a better workaround,
I'm interested to hear it!
Bastiaan
>
>
> All the old CU_* got renamed to CPPUNIT_*.
> I did this with a global string replace. This changes some of the
> MSVC files. I hope they still work. Let me know.
>
> -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
|
|
From: Steve M. R. <ste...@vi...> - 2001-06-05 14:04:40
|
On Tue, Jun 05, 2001 at 01:16:19AM +0200, Bastiaan Bakker wrote: > "Steve M. Robbins" wrote: > > > I've added the generic TestAssert::assertEquals() method, > > along with the new macros CPPUNIT_ASSERT, CPPUNIT_ASSERT_EQUAL, > > and CPPUNIT_ASSERT_DOUBLES_EQUAL. The old naked assert and > > friends are available by editing <cppunit/config.h>. > > > > At the moment, the assertion_traits class requires string streams, > > which does not exist in GCC before version 2.95.3. If you have any > > bright ideas about workarounds for missing <sstream>, I'm all ears. > > In the log4cpp library we encountered the same problem. There we use but > ostringstream, I guess in CppUnit that's all we need too. Ah, that's the hint I needed, thanks! The next chance I get, I'll work out a version of assertion_traits that uses an ostringstream, if HAVE_SSTREAM is not defined. -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 |
|
From: Baptiste L. <bl...@cl...> - 2001-06-06 07:02:07
|
----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: <cpp...@li...>
Sent: Sunday, June 03, 2001 1:49 AM
Subject: [Cppunit-devel] macros and templates
> I've added the generic TestAssert::assertEquals() method,
> along with the new macros CPPUNIT_ASSERT, CPPUNIT_ASSERT_EQUAL,
> and CPPUNIT_ASSERT_DOUBLES_EQUAL. The old naked assert and
> friends are available by editing <cppunit/config.h>.
I've added a default config.h for VC++ (we don't have a configure script
;-( ). When other WIN32 compilers will be added, we can update it to detect
the compiler and set default accordingly.
The new assert equals (I guess) make a compiler internal error in the
cppunittests example. Weird, since it works just fine in another of mine
project. I'll look into that and possible workaround (macro, namespace
instead of class) later.
I think we should add a CPPUNIT_ASSERT_MESSAGE macro, which take a
boolean and a string which is added to the error message. This would allow
the user to create new assertions. For example, you need to compare complex
numbers with a tolerance.
What do you think ?
>
> At the moment, the assertion_traits class requires string streams,
> which does not exist in GCC before version 2.95.3. If you have any
> bright ideas about workarounds for missing <sstream>, I'm all ears.
>
> All the old CU_* got renamed to CPPUNIT_*.
> I did this with a global string replace. This changes some of the
> MSVC files. I hope they still work. Let me know.
Worked just fine.
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).
|
|
From: Steve M. R. <ste...@vi...> - 2001-06-06 13:56:42
|
On Tue, Jun 05, 2001 at 11:50:17PM +0200, Baptiste Lepilleur wrote: > ----- Original Message ----- > From: "Steve M. Robbins" <ste...@vi...> > To: <cpp...@li...> > Sent: Sunday, June 03, 2001 1:49 AM > Subject: [Cppunit-devel] macros and templates > > > > I've added the generic TestAssert::assertEquals() method, > > along with the new macros CPPUNIT_ASSERT, CPPUNIT_ASSERT_EQUAL, > > and CPPUNIT_ASSERT_DOUBLES_EQUAL. The old naked assert and > > friends are available by editing <cppunit/config.h>. > I've added a default config.h for VC++ (we don't have a configure script > ;-( ). Yeah. The lack of a configure script is really unfortunate. And it will only get worse. I expect that there will be an increasing number of HAVE_xxx type of macros defined in one header or another. > When other WIN32 compilers will be added, we can update it to detect > the compiler and set default accordingly. OK. But here's the problem. The file config.h is automatically generated (by configure) from config.h.in. So we don't ship with config.h. Can you write a small script (CONFIGURE.BAT?) for the benefit of WIN systems that don't run configure, that will copy config.h.in to config.h? At the moment, there are in fact, TWO config.h files. That's pretty confusing, I agree. They should have different names. The two files serve different needs. The original config.h is the standard header that autoconf generates. It is intended to contain stuff needed for build-time portability. The symbol HAVE_DLFCN_H is defined, for example, for the benefit of libtool in creating dynamic libraries. The other header, <cppunit/config.h>, is intended to be installed along with the rest of the CppUnit header files. It contains symbol definitions, like CPPUNIT_USE_TYPEINFO, that are used in the other CppUnit headers. Some of these symbols are detected automatically at configure time. So, again, this file does not ship. For systems that can't use the configure script, alternate arrangements are needed. > I think we should add a CPPUNIT_ASSERT_MESSAGE macro, which take a > boolean and a string which is added to the error message. This would allow > the user to create new assertions. For example, you need to compare complex > numbers with a tolerance. > > What do you think ? I think assert-with-message can be useful. For the example you give, an alternative is for the user to write an assertion_traits class for complex numbers that provides a toleranced "equals" method. In fact, one could go the same route for doubles, so I considered the idea of removing CPPUNIT_ASSERT_DOUBLES_EQUAL. Bad idea? -- 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 |
|
From: Baptiste L. <bl...@cl...> - 2001-06-07 20:48:58
|
----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: <cpp...@li...>
Sent: Wednesday, June 06, 2001 3:56 PM
Subject: Re: [Cppunit-devel] macros and templates
> OK. But here's the problem. The file config.h is automatically
> generated (by configure) from config.h.in. So we don't ship with
> config.h. Can you write a small script (CONFIGURE.BAT?) for the benefit
> of WIN systems that don't run configure, that will copy config.h.in
> to config.h?
I'll do that for development time. But I'd like to have config-win32.h
copied to config.h for the tar ball. It will make life a lot easier for
Windows users and that file can easily be removed by the configure script on
Unix.
>
> At the moment, there are in fact, TWO config.h files. That's pretty
> confusing, I agree. They should have different names.
Yes that would make sense.
config-cppunit.h ?
config-portability.h ?
>
> The two files serve different needs. The original config.h is the
> standard header that autoconf generates. It is intended to contain
> stuff needed for build-time portability. The symbol HAVE_DLFCN_H is
> defined, for example, for the benefit of libtool in creating dynamic
> libraries.
Can you post a copy of that file ? Can it be done in such a way that
when a symbol is define it indicate the exception rather than the
"standard". That way I could leave the config file empty, and just add the
symbol when the VC++ platform does not support some standard things.
>
> The other header, <cppunit/config.h>, is intended to be installed
> along with the rest of the CppUnit header files. It contains symbol
> definitions, like CPPUNIT_USE_TYPEINFO, that are used in the other
> CppUnit headers. Some of these symbols are detected automatically at
> configure time. So, again, this file does not ship. For systems
> that can't use the configure script, alternate arrangements are needed.
Ah, I get it. The main difference is that we don't exactly install the
library. There is no standard place for us to put it. So most of the time,
we just add the include directory to the include path and use it from there.
That why having the config.h sitting right in in the global include space is
bothering me.
Also setting are not hard coded in the config file (with the exception
of compiler specifics). This allow us to switch some setting at usage time.
In fact, with VC++ I have two libraries that can be generated: cppunitd.lib
(with type info), and cppunticd.lib (no type info). When you use the
library, you also define the symbol CPPUNIT_DONT_USE_TYPEINFO if your
linking against cppunitcd.lib (which is the one you use if you are going
crossplatform). The most common of this is probably for Debug/Release mode:
two libraries, one set of headers.
> > I think we should add a CPPUNIT_ASSERT_MESSAGE macro, which take a
> > boolean and a string which is added to the error message. This would
allow
> > the user to create new assertions. For example, you need to compare
complex
> > numbers with a tolerance.
> >
> > What do you think ?
>
> I think assert-with-message can be useful.
>
> For the example you give, an alternative is for the user to write an
> assertion_traits class for complex numbers that provides a toleranced
> "equals" method. In fact, one could go the same route for doubles,
> so I considered the idea of removing CPPUNIT_ASSERT_DOUBLES_EQUAL.
> Bad idea?
I don't see how you can specify the tolerance for each assertion using
the traits!?!
It would be better to leave CPPUNIT_ASSERT_DOUBLES_EQUAL here. People
might not be familiar with traits, and the macro is self explaining.
>
>
>
> --
> 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
>
|
|
From: Steve M. R. <ste...@vi...> - 2001-06-08 03:22:18
|
On Thu, Jun 07, 2001 at 10:44:17PM +0200, Baptiste Lepilleur wrote: > ----- Original Message ----- > From: "Steve M. Robbins" <ste...@vi...> > To: <cpp...@li...> > Sent: Wednesday, June 06, 2001 3:56 PM > Subject: Re: [Cppunit-devel] macros and templates > > OK. But here's the problem. The file config.h is automatically > > generated (by configure) from config.h.in. So we don't ship with > > config.h. Can you write a small script (CONFIGURE.BAT?) for the benefit > > of WIN systems that don't run configure, that will copy config.h.in > > to config.h? > I'll do that for development time. But I'd like to have config-win32.h > copied to config.h for the tar ball. It will make life a lot easier for > Windows users and that file can easily be removed by the configure script on > Unix. That's an unorthodox approach, but it will likely work. I'll try it out to see how configure copes with having a config.h file already there. Can you write a single config-win32.h that works for all platforms that don't use configure? The problem of which I'm thinking is this: items like CPPUNIT_USE_TYPEINFO may differ for different compilers on windows. (If not this example, then future additions to this file may differ). If the installer has to hand-edit the file anyway --- to choose the appropriate options --- then why not ask them to rename it as well. You can provide customized config-msv6.h config-borland.h, and whatever. > > At the moment, there are in fact, TWO config.h files. That's pretty > > confusing, I agree. They should have different names. > Yes that would make sense. > config-cppunit.h ? > config-portability.h ? > > > > > The two files serve different needs. The original config.h is the > > standard header that autoconf generates. It is intended to contain > > stuff needed for build-time portability. The symbol HAVE_DLFCN_H is > > defined, for example, for the benefit of libtool in creating dynamic > > libraries. > Can you post a copy of that file ? It is include/config.h, generated from include/config.h.in. The latter is in CVS, so you have a copy. The generated file, on my system is /* include/config.h. Generated automatically by configure. */ /* include/config.h.in. Generated automatically from configure.in by autoheader 2.13. */ /* Define if you have the <dlfcn.h> header file. */ #define HAVE_DLFCN_H 1 /* Name of package */ #define PACKAGE "cppunit" /* Version number of package */ #define VERSION "1.5.5" /* define if the compiler supports Run-Time Type Identification */ #define HAVE_RTTI 1 /* define to 1 if the compiler implements namespaces */ #define HAVE_NAMESPACES 1 /* define if library uses std::string::compare(string,pos,n) */ #define FUNC_STRING_COMPARE_STRING_FIRST 1 > Can it be done in such a way that > when a symbol is define it indicate the exception rather than the > "standard". That way I could leave the config file empty, and just add the > symbol when the VC++ platform does not support some standard things. Maybe. I can't be sure this is going to always be the case. I can guarantee, however, that the input file --- named config.h.in --- will have some useful comments in it. What you need to do is take config.h.in, rename it to config.h, and edit it to suite your environment. > > The other header, <cppunit/config.h>, is intended to be installed > > along with the rest of the CppUnit header files. It contains symbol > > definitions, like CPPUNIT_USE_TYPEINFO, that are used in the other > > CppUnit headers. Some of these symbols are detected automatically at > > configure time. So, again, this file does not ship. For systems > > that can't use the configure script, alternate arrangements are needed. > Ah, I get it. The main difference is that we don't exactly install the > library. There is no standard place for us to put it. So most of the time, > we just add the include directory to the include path and use it from there. > That why having the config.h sitting right in in the global include space is > bothering me. It's not in the global include space. This file is <cppunit/config.h>. It's private to cppunit, if you like. > > For the example you give, an alternative is for the user to write an > > assertion_traits class for complex numbers that provides a toleranced > > "equals" method. In fact, one could go the same route for doubles, > > so I considered the idea of removing CPPUNIT_ASSERT_DOUBLES_EQUAL. > > Bad idea? > I don't see how you can specify the tolerance for each assertion using > the traits!?! You can't. That's the one feature of the current macro that traits can't simulate. > It would be better to leave CPPUNIT_ASSERT_DOUBLES_EQUAL here. People > might not be familiar with traits, and the macro is self explaining. And, yes, the macro name is easy to understand. :-) -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 |
|
From: Baptiste L. <gai...@fr...> - 2001-06-08 16:14:37
|
Quoting "Steve M. Robbins" <ste...@vi...>:
> On Thu, Jun 07, 2001 at 10:44:17PM +0200, Baptiste Lepilleur wrote:
> > ----- Original Message -----
> > From: "Steve M. Robbins" <ste...@vi...>
> > To: <cpp...@li...>
> > Sent: Wednesday, June 06, 2001 3:56 PM
> > Subject: Re: [Cppunit-devel] macros and templates
> > > OK. But here's the problem. The file config.h is automatically
> > > generated (by configure) from config.h.in. So we don't ship with
> > > config.h. Can you write a small script (CONFIGURE.BAT?) for the
> benefit
> > > of WIN systems that don't run configure, that will copy config.h.in
> > > to config.h?
>
> > I'll do that for development time. But I'd like to have
> config-win32.h
> > copied to config.h for the tar ball. It will make life a lot easier
> for
> > Windows users and that file can easily be removed by the configure
> script on
> > Unix.
>
> That's an unorthodox approach, but it will likely work.
> I'll try it out to see how configure copes with having
> a config.h file already there.
OK.
> Can you write a single config-win32.h that works for all platforms
> that don't use configure? The problem of which I'm thinking is this:
> items like CPPUNIT_USE_TYPEINFO may differ for different compilers
> on windows. (If not this example, then future additions to this
> file may differ). If the installer has to hand-edit the file
> anyway --- to choose the appropriate options --- then why not ask
> them to rename it as well. You can provide customized config-msv6.h
> config-borland.h, and whatever.
Yes it can be done. Compiler detection is a common thing (just look at
RogueWave config header).
To me, CPPUNIT_USE_TYPEINFO and CPPUNIT_ENABLED_NAKED_ASSERT are project
specific, not compiler specific (though type info is restricted by your
compiler capability). I might very well for one project use type info since I
know it will never go crossplatform, and in antoher project which is
crossplatform, disabled type info since it is not a portable feature.
The way I did it, is that if the user define (in his project) the symbol
CPPUNIT_DONT_USE_TYPEINFO, then type info won't be enabled.
> It is include/config.h, generated from include/config.h.in. The latter
Something is wrong there, it's was not in CVS when I updated...
> is in CVS, so you have a copy. The generated file, on my system
> is
>
> /* include/config.h. Generated automatically by configure. */
> /* include/config.h.in. Generated automatically from configure.in by
> autoheader 2.13. */
>
> /* Define if you have the <dlfcn.h> header file. */
> #define HAVE_DLFCN_H 1
>
> /* Name of package */
> #define PACKAGE "cppunit"
>
> /* Version number of package */
> #define VERSION "1.5.5"
>
> /* define if the compiler supports Run-Time Type Identification */
> #define HAVE_RTTI 1
>
> /* define to 1 if the compiler implements namespaces */
> #define HAVE_NAMESPACES 1
>
> /* define if library uses std::string::compare(string,pos,n) */
> #define FUNC_STRING_COMPARE_STRING_FIRST 1
Which platforms need this crazy things ? It frighten me that I can't even
rely on a string class...
> > Can it be done in such a way that
> > when a symbol is define it indicate the exception rather than the
> > "standard". That way I could leave the config file empty, and just add
> the
> > symbol when the VC++ platform does not support some standard things.
>
> Maybe. I can't be sure this is going to always be the case.
> I can guarantee, however, that the input file --- named config.h.in ---
> will have some useful comments in it. What you need to do is take
> config.h.in, rename it to config.h, and edit it to suite your
> environment.
OK. That's work for me. Just make sure to keep us posted when a new symbol
is added so I can update that file.
> > > The other header, <cppunit/config.h>, is intended to be installed
> > > along with the rest of the CppUnit header files. It contains symbol
> > > definitions, like CPPUNIT_USE_TYPEINFO, that are used in the other
> > > CppUnit headers. Some of these symbols are detected automatically
> at
> > > configure time. So, again, this file does not ship. For systems
> > > that can't use the configure script, alternate arrangements are
> needed.
> > Ah, I get it. The main difference is that we don't exactly install
> the
> > library. There is no standard place for us to put it. So most of the
> time,
> > we just add the include directory to the include path and use it from
> there.
> > That why having the config.h sitting right in in the global include
> space is
> > bothering me.
>
> It's not in the global include space. This file is <cppunit/config.h>.
> It's private to cppunit, if you like.
I'm okay with that one. I was refering to:
/* include/config.h. Generated automatically by configure. */
which is <config.h> => that's the global include space I was refering to.
> > > For the example you give, an alternative is for the user to write an
> > > assertion_traits class for complex numbers that provides a
> toleranced
> > > "equals" method. In fact, one could go the same route for doubles,
> > > so I considered the idea of removing CPPUNIT_ASSERT_DOUBLES_EQUAL.
> > > Bad idea?
> > I don't see how you can specify the tolerance for each assertion
> using
> > the traits!?!
>
> You can't. That's the one feature of the current macro that traits
> can't simulate.
So it's better to keep the macro. Tolerance is something that is really
specific to each assertion.
Baptiste.
---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/index.html
Language: English, French
|
|
From: Steve M. R. <ste...@vi...> - 2001-06-08 16:55:34
|
On Fri, Jun 08, 2001 at 06:14:33PM +0200, Baptiste Lepilleur wrote: > > /* define if library uses std::string::compare(string,pos,n) */ > > #define FUNC_STRING_COMPARE_STRING_FIRST 1 > Which platforms need this crazy things ? That was because of GCC. They claim to be moving towards compatibility with the C++ stdlib, but clearly they ain't there as of version 2.95.4. > It frighten me that I can't even rely on a string class... You'd be amazed at how little you can really count on, in general. The autoconf manual is full of truly bizarre tests for library and compiler oddities. And C++ is even worse than C. Regards, -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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X