Thread: [Cppunit-devel] Improving CppUnit portability
Brought to you by:
blep
From: Baptiste L. <gai...@fr...> - 2002-07-10 18:48:20
|
CppUnit is getting close to having a stable core. I'd like to start working in an area that has not been really tackled yet: portability. First, I'd like to start making up a list of things that need to be done to make CppUnit more portable. I know some facts, but I hardly have enough experience to know every compilers oddities. Also, I'd like to get feedback on your experience in solving some of those issues. Here is a list of common portability issues I came up with: - Templatized member functions. Solved. TestSuiteBuilder::addTestCallerForException() has been removed. - STL may not be in ::std namespace. I remember someone saying the issue was partially solved doing a : #define std How well does this works ? The solution I came up with is introducing a macro that will decorate a name with 'std' depending on the configuration: #if defined( CPPUNIT_HAVE_STD_NAMESPACE ) # define CPPUNIT_STD( symbol ) std::symbol #else # define CPPUNIT_STD( symbol ) symbol #end While I think this would work (does anybody see an issue with that?), it makes the code less readable. Does anyone have an alternative ? - mutable keyword (?) Only used in MockTestCase of cppunit test suite. Easily removed. - C++ cast (const_cast ...) Easily solved (a few occurences of const_cast). Can be convert to C-style cast. - namespace CppUnit requires the use of namespace as most of the library is placed inside the CppUnit namespace. It should be possible to make that namespace optional by using a macro similar to CPPUNIT_STD (see above), as well as other macros to begin and end CppUnit namespace declaration. A remaining issue would be the TestAssert namespace. It use a templatized functions. Putting that function in a struct to 'simulate' the namespace would introduce a templatized methods (which is a big no no). This function would need to be moved into the global scope. - std::vector.at() Not supported by some (all?) implentation of g++ STL. Solved (not used). Well, that's all I can come up with at the moment. Please let me know of other issues you know of, or problem you see in the proposed solution. Thanks in advance, Baptiste. |
From: Baptiste L. <gai...@fr...> - 2002-07-11 17:02:49
|
----- Original Message ----- From: "Baptiste Lepilleur" <gai...@fr...> To: <cpp...@li...> Sent: Wednesday, July 10, 2002 8:45 PM Subject: [Cppunit-devel] Improving CppUnit portability > - Templatized member functions. > Solved. TestSuiteBuilder::addTestCallerForException() has been > removed. Forgot another item related to template: - Default template argument Issue: TestCaller use a default template argument to filter no exception. Solution: should be solved when the following item of the TODO list is done: Provide a mean for the user to catch 'custom' exception in TestCase::run (exception that do not subclass std::exception, such as MFC CException, or RogueWave RWXMsg). TestCaller will probably not need to test for expected exception... > - STL may not be in ::std namespace. > I remember someone saying the issue was partially solved doing a : > #define std > How well does this works ? I looked at STLPort (http://stlport.org/) some and they do just that (for lowly conformant compiler). So I'll go that way, it keep the code 'clean'. I'll just add an epilog header which will restore 'std' to whatever is was before it was defined by CppUnit. > - mutable keyword (?) > Only used in MockTestCase of cppunit test suite. Easily removed. Done. Use const_cast now. > - C++ cast (const_cast ...) > Easily solved (a few occurences of const_cast). Can be convert to > C-style cast. Done. Use a macro that expands to const_cast if possible or do a C-style cast (there was just about 5 occurences). Baptiste. |
From: Baptiste L. <gai...@fr...> - 2002-07-14 19:50:22
|
Finaly done with most of the change. The trickest was getting around the need to provide the STL allocator for compiler that do not support default template parameter. Curious may give a look to the new CodingGuideLines.txt file in CppUnit root directory to have an idea of what is involved. The only things left to deal with is TestCaller default template parameter. Comments are welcome, Baptiste. ----- Original Message ----- From: "Baptiste Lepilleur" <gai...@fr...> To: <cpp...@li...> Sent: Thursday, July 11, 2002 6:42 PM Subject: Re: [Cppunit-devel] Improving CppUnit portability > ----- Original Message ----- > From: "Baptiste Lepilleur" <gai...@fr...> > To: <cpp...@li...> > Sent: Wednesday, July 10, 2002 8:45 PM > Subject: [Cppunit-devel] Improving CppUnit portability > > > > - Templatized member functions. > > Solved. TestSuiteBuilder::addTestCallerForException() has been > > removed. > > Forgot another item related to template: > > - Default template argument > Issue: TestCaller use a default template argument to filter no > exception. > Solution: should be solved when the following item of the TODO list > is done: > > Provide a mean for the user to catch 'custom' exception in > TestCase::run (exception that do not subclass std::exception, such as MFC > CException, or RogueWave RWXMsg). > > TestCaller will probably not need to test for expected exception... --- Baptiste Lepilleur <gai...@fr...> http://gaiacrtn.free.fr/ |
From: Volker B. <boe...@we...> - 2002-07-15 08:43:17
|
On Wed, 10 Jul 2002, Baptiste Lepilleur wrote: > CppUnit is getting close to having a stable core. I'd like to start > working in an area that has not been really tackled yet: portability. > > First, I'd like to start making up a list of things that need to be done > to make CppUnit more portable. I know some facts, but I hardly have enough > experience to know every compilers oddities. Also, I'd like to get feedback > on your experience in solving some of those issues. I find ACE (http://www.cs.wustl.edu/~schmidt/ACE.html) a very good source on many portability issues. ACE runs on a number of platforms I'ld never like to work on, namely compilers missing namespace or even exception support. ACE uses a lot of preprocessor macros to hide most of the platform differences. I think that's fine given that C++ is not as portable as Java (at least as it would be without the preprocessor trickery...). See e.g. how the configuration item ACE_HAS_ANSI_CASTS from http://cvs.doc.wustl.edu/ace-cvs.cgi/ACE_wrappers/ace/config-g++-common.h is used in http://cvs.doc.wustl.edu/ace-cvs.cgi/ACE_wrappers/ace/config-all.h to define the macro ACE_const_cast(TYPE, EXPR) which expands to the proper const_cast<> on platforms which support it and to old style cast only where necessary. Regards, Volker -- Volker Boerchers, boe...@we... |