[Cppunit-devel] Improving CppUnit portability

[Baptiste L. <gai...@fr...>]

    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.