cppunit-devel Mailing List for CppUnit - C++ port of JUnit (Page 58)
Brought to you by:
blep
Menu
▾
▴
cppunit-devel — CppUnit Developer Mailing List
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
(21) |
May
(96) |
Jun
(109) |
Jul
(42) |
Aug
(6) |
Sep
(106) |
Oct
(60) |
Nov
(20) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(7) |
Feb
(11) |
Mar
(49) |
Apr
(124) |
May
(30) |
Jun
(37) |
Jul
(53) |
Aug
(33) |
Sep
(21) |
Oct
(22) |
Nov
(19) |
Dec
(15) |
| 2003 |
Jan
(34) |
Feb
(25) |
Mar
(11) |
Apr
(12) |
May
(16) |
Jun
(24) |
Jul
(23) |
Aug
(23) |
Sep
(42) |
Oct
(7) |
Nov
(32) |
Dec
(33) |
| 2004 |
Jan
(41) |
Feb
(41) |
Mar
(24) |
Apr
(25) |
May
(18) |
Jun
(13) |
Jul
(11) |
Aug
(15) |
Sep
(22) |
Oct
(10) |
Nov
(15) |
Dec
(9) |
| 2005 |
Jan
(4) |
Feb
(15) |
Mar
(11) |
Apr
(16) |
May
(29) |
Jun
(17) |
Jul
(27) |
Aug
(12) |
Sep
(9) |
Oct
(10) |
Nov
(5) |
Dec
(6) |
| 2006 |
Jan
(2) |
Feb
(6) |
Mar
(7) |
Apr
(2) |
May
(1) |
Jun
(5) |
Jul
(8) |
Aug
(6) |
Sep
(10) |
Oct
(11) |
Nov
(15) |
Dec
(2) |
| 2007 |
Jan
(12) |
Feb
(22) |
Mar
(10) |
Apr
(7) |
May
(1) |
Jun
(8) |
Jul
(4) |
Aug
(1) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
(7) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
|
| 2010 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Baptiste L. <bl...@cl...> - 2001-06-06 07:02:07
|
----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: "CppUnit Development" <cpp...@li...>
Sent: Sunday, June 03, 2001 2:46 AM
Subject: [Cppunit-devel] TestRunner
>
> Looking at the documentation generated using Doxygen,
> I see that there is ONE class defined outside the CppUnit
> namespace, namely TestRunner.
>
> Is this a simple oversight?
> Or is it intended only as example code?
TestRunner is the GUI TestRunner for VC++. It is not in the CppUnit
namespace because I did not want to take that name within the namespace.
If you have suggestions about the name/namespace, they are welcome.
>
> In the latter case, we can simply exclude the relevant
> directories from Doxygen's input.
>
> -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
>
|
|
From: Steve M. R. <ste...@vi...> - 2001-06-05 22:26:23
|
Hi all,
We're going to need to start communicating, or there will be a lot of
toes begin stepped on. Please: if something seems weird to you, ask
about it. Don't assume.
I don't want to single people out, but here's what I see recently
checked in:
* src/cppunit/TypeInfoHelper.cpp: removed #include <config.h>,
cppunit/config.h was already included.
This is wrong. <config.h> and <cppunit/config.h> are two different files.
Both must be included.
* added include/cppunit/config.h with a default configuration for VC++ 6.0.
This is a bad idea. This file is generated from config.h.in. If you want
a default for VC++ 6.0, then include it with a different name, like
config.h.msvc6. Then copy it or symlink it by hand. You only need do
it once.
* include/cppunit/.cvsignore: removed config.h from the list of ignored file.
This is a bad idea. It is a generated file. See previous.
Thanks,
-Steve
--
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants
|
|
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: 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-03 00:46:22
|
Looking at the documentation generated using Doxygen, I see that there is ONE class defined outside the CppUnit namespace, namely TestRunner. Is this a simple oversight? Or is it intended only as example code? In the latter case, we can simply exclude the relevant directories from Doxygen's input. -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: 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: Baptiste L. <bl...@cl...> - 2001-06-02 08:39:25
|
----- Original Message -----
From: "Bastiaan Bakker" <bas...@li...>
To: <cpp...@li...>
Sent: Saturday, June 02, 2001 12:12 AM
Subject: Re: [Cppunit-devel] Added cppunittest examples...
> Baptiste Lepilleur wrote:
> Both the TestCallerTest and TestResultTest do rely on RTTI: they use the
> default constructor of TestBuilderSuite, which only exists if
> CU_USE_TYPEINFO has been defined. I've changed these to use the
> constructor with the name parameter.
> Test results on x86 RH Linux 7.1 i with g++ 2.96 RH 81 are 10 times OK.
Thanks, I completly forgot about that one... I think I'll do two
configurations like for the library, one with typeinfo (they need to be
test) and one without.
---
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: Bastiaan B. <bas...@li...> - 2001-06-01 22:02:24
|
Baptiste Lepilleur wrote: >I needed something to test the TestListener, and a while ago I suggested >creating unit tests for cppunit. > >Well, this is done. I added a new example named cppunittest. It implements >unit test for TestCaller and TestListener. There is also a graphical test >runner hidden in examples/msvc6. > >You will need to add a make file for unix though. > Done. > > >I used only cppunit features that are not too advanced (no template method, >no RTTI) to write the unit test. > Both the TestCallerTest and TestResultTest do rely on RTTI: they use the default constructor of TestBuilderSuite, which only exists if CU_USE_TYPEINFO has been defined. I've changed these to use the constructor with the name parameter. Test results on x86 RH Linux 7.1 i with g++ 2.96 RH 81 are 10 times OK. > >I think that project is (will become) an excellent example since it >implement some real live test! > >So what do you think ? > yes, I like it! It's much more interesting than the hierarchy example. Thanks, Bastiaan > >Baptiste. > >--- >Baptiste Lepilleur <gai...@fr...> http://gaiacrtn.free.fr/index.html >Author of The Text Reformatter, a tool for fanfiction readers and writers. >Language: English, French (Well, I'm French). > > >_______________________________________________ >Cppunit-devel mailing list >Cpp...@li... >http://lists.sourceforge.net/lists/listinfo/cppunit-devel > |
|
From: Bastiaan B. <bas...@li...> - 2001-06-01 21:52:14
|
Steve M. Robbins wrote: >On Fri, Jun 01, 2001 at 11:34:35PM +0200, Bastiaan Bakker wrote: > > >>I've added a Makefile.am to examples/cppunittest. Now it tries to >>compile the code, g++ gives an error though: >> >>TestCallerTest.cpp:24: ISO C++ forbids taking the address of a bound >>member function to form a pointer to member function >> > >You can't say "&foo" if foo is a member function of class X. >Use "&X::foo", instead. > Yes, I figured that out too. I find the error messages somewhat cryptic sometimes, especially when the C++ nowhere contains the term 'bound member function'. Thanks, Bastiaan > >-Steve > > |
|
From: Steve M. R. <ste...@vi...> - 2001-06-01 21:32:58
|
On Fri, Jun 01, 2001 at 11:34:35PM +0200, Bastiaan Bakker wrote: > I've added a Makefile.am to examples/cppunittest. Now it tries to > compile the code, g++ gives an error though: > > TestCallerTest.cpp:24: ISO C++ forbids taking the address of a bound > member function to form a pointer to member function You can't say "&foo" if foo is a member function of class X. Use "&X::foo", instead. -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-01 21:24:15
|
Steve M. Robbins wrote: >On Fri, Jun 01, 2001 at 09:43:46PM +0200, Baptiste Lepilleur wrote: > >>I needed something to test the TestListener, and a while ago I suggested >>creating unit tests for cppunit. >> >>Well, this is done. I added a new example named cppunittest. It implements >>unit test for TestCaller and TestListener. There is also a graphical test >>runner hidden in examples/msvc6. >> >>You will need to add a make file for unix though. >> > >So I noticed :( > >Making all in cppunittest >make[2]: Entering directory `/usr/local/src/devel/cppunit-cvs/examples/cppunittest' >make[2]: *** No rule to make target `all'. Stop. >make[2]: Leaving directory `/usr/local/src/devel/cppunit-cvs/examples/cppunittest' >make[1]: *** [all-recursive] Error 1 > > > I've added a Makefile.am to examples/cppunittest. Now it tries to compile the code, g++ gives an error though: TestCallerTest.cpp:24: ISO C++ forbids taking the address of a bound member function to form a pointer to member function I'll try to figure out what the problem is. Bastiaan |
|
From: Steve M. R. <ste...@vi...> - 2001-06-01 19:53:27
|
On Fri, Jun 01, 2001 at 09:43:46PM +0200, Baptiste Lepilleur wrote: > I needed something to test the TestListener, and a while ago I suggested > creating unit tests for cppunit. > > Well, this is done. I added a new example named cppunittest. It implements > unit test for TestCaller and TestListener. There is also a graphical test > runner hidden in examples/msvc6. > > You will need to add a make file for unix though. So I noticed :( Making all in cppunittest make[2]: Entering directory `/usr/local/src/devel/cppunit-cvs/examples/cppunittest' make[2]: *** No rule to make target `all'. Stop. make[2]: Leaving directory `/usr/local/src/devel/cppunit-cvs/examples/cppunittest' make[1]: *** [all-recursive] Error 1 -- 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-01 19:36:42
|
I added the TestListener to TestResult as suggested by Steves. This is a port of junit TestListener. Let's me know if you see anything wrong. Look out for concurency issue (VC++ testrunner run the test in a separate thread). 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: Baptiste L. <bl...@cl...> - 2001-06-01 19:30:18
|
I needed something to test the TestListener, and a while ago I suggested creating unit tests for cppunit. Well, this is done. I added a new example named cppunittest. It implements unit test for TestCaller and TestListener. There is also a graphical test runner hidden in examples/msvc6. You will need to add a make file for unix though. I used only cppunit features that are not too advanced (no template method, no RTTI) to write the unit test. I think that project is (will become) an excellent example since it implement some real live test! So what do you think ? Baptiste. --- Baptiste Lepilleur <gai...@fr...> http://gaiacrtn.free.fr/index.html Author of The Text Reformatter, a tool for fanfiction readers and writers. Language: English, French (Well, I'm French). |
|
From: Townsend, G. <gto...@sh...> - 2001-05-31 19:24:45
|
> BTW this makes me very curious about how many people are > using CppUnit in a production environment. FWIW, I had just started to play with CppUnit before it became a SF project. I have been using 1.5.5, but only the very basics because there is so much change going on. I don't want to have to change everything later. So for now I'm just using TestCase and TestSuite, with a commandline interface to show results. There are a lot of improvements happening so I am willing to wait a little while. But I really want to have a CppUnit project under source control, and which all of my other projects can use. And of course I don't want all my projects to break because an interface changed in CppUnit. Regarding the current changes being made: It seems to me that if people were using the original version before it became an active project, then they have the choice to continue to use that version or upgrade to the SF version and get a cleaner design and more functionality. But sometime fairly soon, I do think that CppUnit should get a very stable interface such that people can depend on. Previously I think it was CppUnit was explicitly not supported by Michael Feather. Now that it's a SF project, people will expect that it is a serious tool that they can count on to maintain backwards compatibility. That said, the Development Status of CppUnit on SF is shown as Pre-Alpha. I cannot imagine any reasonable person (developer) thinking that Pre-Alpha means things are not changing! ( Seems that the development status probably is ready to be changed on the next release to at least something much closer to Released status. ) Once the status gets to a beta status, then changes that might break code become worthy of a lot more concern and thought. Guy |
|
From: Steve M. R. <ste...@vi...> - 2001-05-31 13:35:01
|
On Wed, May 30, 2001 at 11:04:34AM +0200, Bastiaan Bakker wrote: > On Tue, May 29, 2001 at 12:03:15PM -0700, Townsend, Guy wrote: > > > From: Steve M. Robbins > > > Since there are already CU_-prefixed macros, I'm planning > > > to use CU_assert unless I hear a better suggestion. > > > > I already mentioned it, but just to reiterate it here, I ask the question > > whether macros shoudn't be all caps? > > It is true that macros have a long history of being all caps. > > I hereby amend my post of yesterday to read "I'm planning to convert > to CU_ASSERT unless I hear a better suggestion". > > Sofar I've not payed very much attention to the macro prefixes yet, but I > would like to suggest we go for the slightly longer 'CPPUNIT' prefix: Ha! This almost brings me full circle: I had originally used "CppUnit_assert()" for the macro name. Since UPPERCASE seems popular for macros, that would become CPPUNIT_ASSERT, instead. > It's more in line with the CppUnit namespace we already claim and the header > guard defines. > CU may be too short to avoid naming collisions with other libraries, > especially because of the phonetic 'see you' association. I agree with what you say. I had suggested CU_ only because it was already there. I'm fine with CPPUNIT as long as it is used everywhere. Therefore, I will change CU_* --> CPPUNIT_* everywhere it appears. -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: Steve M. R. <ste...@vi...> - 2001-05-31 13:18:34
|
On Tue, May 29, 2001 at 11:58:36PM +0200, Baptiste Lepilleur wrote: > > On Wed, May 23, 2001 at 05:06:45PM -0400, Steve M. Robbins wrote: > > 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. > Have you found a way to specify which TestResult the TestRunner should > use ? I'm not using TestRunner. -- 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: Peer S. <pee...@ne...> - 2001-05-31 06:57:57
|
Bastiaan Bakker wrote: > BTW this makes me very curious about how many people are using CppUnit in a > production environment. So far I haven't been concerned too much about > backward compatibility, because the 1.5.3 release was broken. But I may be > wrong? Why not make a survey at sourceforge? -- Peer Sommerlund, NetMan A/S, Vandtaarnsvej 77, DK-2860 Soeborg, Denmark Email: pe...@ne..., Phone: (+45) 39 53 58 00, Fax: (+45) 39 53 58 58 |
|
From: Baptiste L. <bl...@cl...> - 2001-05-30 18:26:30
|
----- Original Message -----
From: "Steve M. Robbins" <ste...@vi...>
To: <cpp...@li...>
Sent: Tuesday, May 29, 2001 9:47 PM
Subject: Re: [Cppunit-devel] ch-ch-ch-changes ...
> On Tue, May 29, 2001 at 12:03:15PM -0700, Townsend, Guy wrote:
> >
> >
> > > -----Original Message-----
> > > From: Steve M. Robbins
> > > Since there are already CU_-prefixed macros, I'm planning
> > > to use CU_assert unless I hear a better suggestion.
> >
> > I already mentioned it, but just to reiterate it here, I ask the
question
> > whether macros shoudn't be all caps?
>
> It is true that macros have a long history of being all caps.
>
> I hereby amend my post of yesterday to read "I'm planning to convert
> to CU_ASSERT unless I hear a better suggestion".
I'll go for that, or cu_assert. I kind of prefer the later since it is
emulating a function call (and it would be nice if we could have it working
without macro even if there is information loss) and does attrack the eyes
as much as you read the code.
> That suggests to not even bother with a configure-time switch that
> would enable the old macros. Rather, they would be protected using
> something like
>
> #if CU_ENABLE_NAKED_ASSERT
> # define assert(c) CU_ASSERT(c)
> ...
> #endif
>
> Not a bad idea...
Funny, I was about to suggest something like that. Enable both form to
make migration easy...
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: Baptiste L. <bl...@cl...> - 2001-05-30 18:26:12
|
> On Wed, May 23, 2001 at 05:06:45PM -0400, Steve M. Robbins wrote:
> 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.
Have you found a way to specify which TestResult the TestRunner should
use ?
>
> 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.
Yes, that's probably the best. If your doing a GUI you more or less end
up rewriting that to enable incremental report anyway...
> 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?
Not really. Somewhere on wiki Michael Feather's said that having no
const method makes refactoring C++ easier (not his exact wording. It was on
the C++ XP challenge discussion I think). So Michael Feather's version does
not have any const methods. Constness have been added on sourceforge version
and there might be some missing...
> 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.
It works ok on VC++, but I guess there might be some problem on other
platforms... Though I'd really like to know which. It impossible to write a
multithreaded programm without having to make locks mutable when you use
const method, and I don't really like using macro for that...
|
|
From: Bastiaan B. <bas...@li...> - 2001-05-30 17:41:42
|
-----Oorspronkelijk bericht----- Van: Steve M. Robbins [mailto:ste...@vi...] Verzonden: Tuesday, May 29, 2001 9:47 PM Aan: cpp...@li... Onderwerp: Re: [Cppunit-devel] ch-ch-ch-changes ... On Tue, May 29, 2001 at 12:03:15PM -0700, Townsend, Guy wrote: > > > > -----Original Message----- > > From: Steve M. Robbins > > Since there are already CU_-prefixed macros, I'm planning > > to use CU_assert unless I hear a better suggestion. > > I already mentioned it, but just to reiterate it here, I ask the question > whether macros shoudn't be all caps? It is true that macros have a long history of being all caps. I hereby amend my post of yesterday to read "I'm planning to convert to CU_ASSERT unless I hear a better suggestion". Sofar I've not payed very much attention to the macro prefixes yet, but I would like to suggest we go for the slightly longer 'CPPUNIT' prefix: It's more in line with the CppUnit namespace we already claim and the header guard defines. CU may be too short to avoid naming collisions with other libraries, especially because of the phonetic 'see you' association. > > I'm also planning to make a backwards-compatibility configure switch > > to enable the current "assert()" macro. My natural inclination is to > > discourage the use of naked assert() by disabling it in the default > > build (i.e. if the switch is NOT given). However, that's a bit > > obnoxious if CppUnit has a long history of using the naked assert(). > > What is the general feeling about this? > > My personal feeling is that since it conflicts with a standard C++ library > macro the original inclusion should be treated as a bug, and it should be > "fixed" (by making it NOT the default behavior). There absolutely needs to > be mention of it in release notes and in the header file. But I think it's > time to bite the bullet and make the change. Reminds me of the XP process: > When code is found to be wrong, just fix it. make whatever adjustments are > necessary, and move on. Never to be bothered by that ugliness again. > > Sure, there should be a way to turn the switch on at a project level, but > that is a small change to a makefile after discovering that assert() is > undefined. That suggests to not even bother with a configure-time switch that would enable the old macros. Rather, they would be protected using something like #if CU_ENABLE_NAKED_ASSERT # define assert(c) CU_ASSERT(c) ... #endif Not a bad idea... Yes, go for it. Let's get rid of this rude assert define asap. > Steve, I certainly appreciate your contributions to the project. I haven't > had time to any actual code contribution yet, but I sure appreciate those > who are doing so. Thanks. I appreciate the constructive feedback. It is critical for those using (or planning to use) CppUnit to speak up *now*. Namespace decisions, and the like are going to haunt us forever if we get them wrong. Or at least until version 2 :-) BTW this makes me very curious about how many people are using CppUnit in a production environment. So far I haven't been concerned too much about backward compatibility, because the 1.5.3 release was broken. But I may be wrong? Bastiaan -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-05-29 19:47:22
|
On Tue, May 29, 2001 at 12:03:15PM -0700, Townsend, Guy wrote: > > > > -----Original Message----- > > From: Steve M. Robbins > > Since there are already CU_-prefixed macros, I'm planning > > to use CU_assert unless I hear a better suggestion. > > I already mentioned it, but just to reiterate it here, I ask the question > whether macros shoudn't be all caps? It is true that macros have a long history of being all caps. I hereby amend my post of yesterday to read "I'm planning to convert to CU_ASSERT unless I hear a better suggestion". > > I'm also planning to make a backwards-compatibility configure switch > > to enable the current "assert()" macro. My natural inclination is to > > discourage the use of naked assert() by disabling it in the default > > build (i.e. if the switch is NOT given). However, that's a bit > > obnoxious if CppUnit has a long history of using the naked assert(). > > What is the general feeling about this? > > My personal feeling is that since it conflicts with a standard C++ library > macro the original inclusion should be treated as a bug, and it should be > "fixed" (by making it NOT the default behavior). There absolutely needs to > be mention of it in release notes and in the header file. But I think it's > time to bite the bullet and make the change. Reminds me of the XP process: > When code is found to be wrong, just fix it. make whatever adjustments are > necessary, and move on. Never to be bothered by that ugliness again. > > Sure, there should be a way to turn the switch on at a project level, but > that is a small change to a makefile after discovering that assert() is > undefined. That suggests to not even bother with a configure-time switch that would enable the old macros. Rather, they would be protected using something like #if CU_ENABLE_NAKED_ASSERT # define assert(c) CU_ASSERT(c) ... #endif Not a bad idea... > Steve, I certainly appreciate your contributions to the project. I haven't > had time to any actual code contribution yet, but I sure appreciate those > who are doing so. Thanks. I appreciate the constructive feedback. It is critical for those using (or planning to use) CppUnit to speak up *now*. Namespace decisions, and the like are going to haunt us forever if we get them wrong. -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: Townsend, G. <gto...@sh...> - 2001-05-29 19:07:22
|
> -----Original Message----- > From: Steve M. Robbins > Since there are already CU_-prefixed macros, I'm planning > to use CU_assert unless I hear a better suggestion. I already mentioned it, but just to reiterate it here, I ask the question whether macros shoudn't be all caps? Seems there is no coding standard for this project, and I wonder if it is worth adopting one. I'm less concerned about which standard than whether there is one. Of course one that seems to please the most people is best, but that discussion could go on for a long time. Perhaps only those that have cvs write access get a vote? That should shorten the discussion. The Corelinux Consortium C++ Coding Standards is one possibility. It seems to be one of the best that I've found. http://corelinux.sourceforge.net/cppstnd.php > I'm also planning to make a backwards-compatibility configure switch > to enable the current "assert()" macro. My natural inclination is to > discourage the use of naked assert() by disabling it in the default > build (i.e. if the switch is NOT given). However, that's a bit > obnoxious if CppUnit has a long history of using the naked assert(). > What is the general feeling about this? My personal feeling is that since it conflicts with a standard C++ library macro the original inclusion should be treated as a bug, and it should be "fixed" (by making it NOT the default behavior). There absolutely needs to be mention of it in release notes and in the header file. But I think it's time to bite the bullet and make the change. Reminds me of the XP process: When code is found to be wrong, just fix it. make whatever adjustments are necessary, and move on. Never to be bothered by that ugliness again. Sure, there should be a way to turn the switch on at a project level, but that is a small change to a makefile after discovering that assert() is undefined. And hopefully the release notes are read first, and it's no suprise. Steve, I certainly appreciate your contributions to the project. I haven't had time to any actual code contribution yet, but I sure appreciate those who are doing so. Guy |
|
From: Townsend, G. <gto...@sh...> - 2001-05-29 18:29:58
|
> On Fri, May 25, 2001 at 03:28PM -0700, Steve M. Robbins wrote: > > 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). Which really argues for assert() being changed to CU_ASSERT(). Since it's a macro, shouldn't it be all upper case. The compiler vendors get away with it because of the C library having two versions of many functions, but it's certainly standard practice for others to capitalize macros. (Microsoft has already stolen ASSERT() for MFC, so that is not a good choice either; besides the fact that a library like CppUnit should use its own prefix for anything in the global name space) > 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). I like that. (though the all caps for macros question comes up again). Making TestAssert::assertEquals() be a templated function sounds interesting. Gets around all the variations of that function. On the other hand I don't have anything useful to contribute to the discussion of compiler support, so other than "that sounds good (in theory)" I'll just watch to see how it works out. Guy |
|
From: Steve M. R. <ste...@vi...> - 2001-05-28 18:01:52
|
Hullo, Bastiaan Bakker has invited me to participate more closely in developing CppUnit, and has granted me cvs write access. So my plan for the next few days is to go through the stuff I've been proposing over the last weeks. I'll commit the small stuff like documentation fixes first. I'll post a warning before committing larger changes. If I've proposed something very objectionable, do let me know. The two main large changes that I want to get in are: 1. the templated assertEqual() and its related macro, and 2. having all macros (in particular "assert") prefixed. Since there are already CU_-prefixed macros, I'm planning to use CU_assert unless I hear a better suggestion. I'm also planning to make a backwards-compatibility configure switch to enable the current "assert()" macro. My natural inclination is to discourage the use of naked assert() by disabling it in the default build (i.e. if the switch is NOT given). However, that's a bit obnoxious if CppUnit has a long history of using the naked assert(). What is the general feeling about this? -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 |
180 messages has been excluded from this view by a project administrator.
