Thread: RE: [Cppunit-devel] Improving CppUnit portability
Brought to you by:
blep
From: Michel A. <Arm...@si...> - 2002-07-11 07:04:25
|
Hi. I am not an expert in the field of portability, but I don't like the idea to get rid of the C++ style casts (for instance). These kinds of casts (static_cast, dynamic_cast, reinterprete_cast) are more safe with respect to type safety and are - AFAIK - perfectly standarized C++ features. Cutting down on C++ features would ulitmately end up in the question whether we'd like to implement CppUnit with C++ or with just C. Coming from a Java playground, I also do not like the idea of introducing too many "MACRO-magics", because they just tend to complicate things, for example when it comes down to refactoring issues. I'd prefer, if we could concentrate more on getting rid of OS-specifics than on compiler-specifics. Of course, compiler specifics are also a big issue, but I hope it will be sufficient, if we support the "more mature" C++ implementations that already provide the usual common set of features of C++. Regards Armin > -----Original Message----- > From: Baptiste Lepilleur [mailto:gai...@fr...] > Sent: Mittwoch, 10. Juli 2002 20:45 > To: cpp...@li... > Subject: [Cppunit-devel] Improving CppUnit portability > > > 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. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Two, two, TWO treats in one. > http://thinkgeek.com/sf > _______________________________________________ > Cppunit-devel mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cppunit-devel > |
From: Baptiste L. <gai...@fr...> - 2002-07-11 17:42:45
|
----- Original Message ----- From: "Michel Armin" <Arm...@si...> To: <cpp...@li...> Sent: Thursday, July 11, 2002 9:03 AM Subject: RE: [Cppunit-devel] Improving CppUnit portability > Hi. > > I am not an expert in the field of portability, but I don't like the idea to > get rid of the C++ style casts (for instance). These kinds of casts > (static_cast, dynamic_cast, reinterprete_cast) are more safe with respect to > type safety and are - AFAIK - perfectly standarized C++ features. Cutting > down on C++ features would ulitmately end up in the question whether we'd > like to implement CppUnit with C++ or with just C. While I would agree with this for a 'real' project, CppUnit uses only 5 const_cast (to implement constness semantic). Hardly a reason for not supporting some compilers... > Coming from a Java playground, I also do not like the idea of introducing > too many "MACRO-magics", because they just tend to complicate things, for > example when it comes down to refactoring issues. I turned down from the CPPUNIT_STD macro (see other post). Remaining macros will not disturb things that much. > I'd prefer, if we could concentrate more on getting rid of OS-specifics than > on compiler-specifics. Of course, compiler specifics are also a big issue, > but I hope it will be sufficient, if we support the "more mature" C++ > implementations that already provide the usual common set of features of > C++. What are you refering to ? The only OS dependency that I'm aware of is the DynamicLibraryManager class, which is already portable. The plug-in system can be made optional if need be. Well, and some part of the build system (see bug/support), but I can't do much about that. This leave compiler stuff as the most important thing in the way. As I see things, it should be possible to compile CppUnit on all the platforms supported by STLPort which provides exception support and iostream. If they can get the STL working, we surely can provide something as simple as CppUnit. CppUnit should not be the force that will make you choose/upgrade your compiler. The more people can use CppUnit, the better. If you look hard enough on the net, you will even find version of CppUnit where the STL where completly removed. I don't believe we need to go that far (STLPort seems to be available on a fair amount of platforms), but there is clearly a need... Baptiste. > > Regards > > Armin |