RE: [Cppunit-devel] Improving CppUnit portability

[Michel A. <Arm...@si...>]

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
>