Thread: RE: [Cppunit-devel] ch-ch-ch-changes ...
Brought to you by:
blep
Menu
▾
▴
cppunit-devel
|
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: 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: 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: 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: 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-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: 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).
|
×
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