Frühlingsröllchen, Chili-Pfeffer-Dip, Reis, Eisberg mit Möhren, Kokosquark

-Wall -Wextra

will generate a lot of useful warning messages about unused parameters etc.
Unfortunately, this is not the common practice and often the own compiler settings concerning the warning level results in dozens of warnings from system headers on which the own code relies, making it impossible to spot warnings from your own code in the endless mass of console output.
Fortunately, GCC has a way to ignore warnings from foreign headers. Instead of using -I to specify an include path, -isystem tells the compiler to treat the includes from the given path as system headers where no warnings should be reported.

If CMake is used to create the Makefile, a special argument to the INCLUDE_DIRECTORIES function generates these compiler flags:

INCLUDE_DIRECTORIES(SYSTEM /usr/include /and/other /system/paths)

1. Change the compiler flags. The worst solution. In other cases these warnings are really helpful. Generally I really like to compile with the highest warning level. Most of the warnings (at least for GCC) really have something to tell.
2. Use a macro to flag a variable as being unused, e.g. from Qt:

   foo(int aParameter) {
       Q_UNUSED(aParameter)
   }
   

   Eventhough this looks like a reasonable solution it has the drawback of having a potential for confusion.  Maybe sometime later you need the parameter but forget to remove the Q_UNUSED macro, hence generating something like this:

   foo(int aParameter) {
       Q_UNUSED(aParameter)
       // 30 lines of other method code
       int anotherVariable = 30 * aParameter;
   }
   

   Suddenly your code documents that a variable isn’t used but actually it is and the compiler can’t detect this error.

3. Simply comment the variable name:

   foo(int /*aParameter*/) {
       // 30 lines of other method code
       int anotherVariable = 30 * aParameter;
   }
   

   Now the warning is gone, too and the compiler can detect either the illegal use of the variable in line three or the illegal statement that this variable is unused by purpose.

SET(HS folder/test.h folder/other/test2.h)

A simple call to INSTALL doesn’t preserve the folder structure:

INSTALL(FILES ${HS} DESTINATION include)

This results in all files being directly under $prefix/include.

To preserve the structure you can use this simple macro:

MACRO(INSTALL_HEADERS_WITH_DIRECTORY HEADER_LIST)

FOREACH(HEADER ${${HEADER_LIST}})
    STRING(REGEX MATCH "(.*)[/\\]" DIR ${HEADER})
    INSTALL(FILES ${HEADER} DESTINATION include/${DIR})
ENDFOREACH(HEADER)

ENDMACRO(INSTALL_HEADERS_WITH_DIRECTORY)

INSTALL_HEADERS_WITH_DIRECTORY(HS)

#include <sstream>

#include <log4cxx/basicconfigurator.h>

#include <boost/test/included/unit_test.hpp>

#include <gtest/gtest.h>
#include <gmock/gmock.h>

using namespace std;
using namespace testing;

class BoostTestAdapter: public EmptyTestEventListener {

    virtual void OnTestStart(const TestInfo& /*testInfo*/) {
    }

    virtual void OnTestPartResult(
            const TestPartResult& testPartResult) {
        if (testPartResult.failed()) {
            stringstream s;
            s << "Mock test failed (file = '"
              << testPartResult.file_name()
              << "', line = "
              << testPartResult.line_number()
              << "): "
              << testPartResult.summary();
            BOOST_FAIL(s.str());
        }
    }

    virtual void OnTestEnd(
            const ::testing::TestInfo& /*testInfo*/) {
    }

};

Every time a partial test result of googletest is reported that fails, BOOST_FAIL is called.

The only thing that is left now is to install the newly created adapter in the googletest framework and initialize it properly. This can be done using a fixture class in Boost Test:

class TestFixture {
public:

    TestFixture() {

        InitGoogleMock(
                &boost::unit_test::framework::master_test_suite().argc,
                boost::unit_test::framework::master_test_suite().argv);
        TestEventListeners &listeners =
                UnitTest::GetInstance()->listeners();
        // this removes the default error printer
        delete listeners.Release(
                listeners.default_result_printer());
        listeners.Append(new BoostTestAdapter);

    }

    ~TestFixture() {
        // nothing to tear down
    }

};
BOOST_GLOBAL_FIXTURE(TestFixture)

Enable Doxygen support for Eclipse CDT.

With this, Doxygen tags in comments are highlighted and comments with parameters etc. are generated automatically like in Java. What’s still missing is the auto-formatter support for these comments and tag-completion.

The game we developed is based on the well known Pong but extends it with some interesting tweaks like two paddles per player etc.

Here are the downloads:

• PongEvolutions d64 image
• PongEvolutions Booklet / Manual

The game should be playable on every modern C64 emulator or the real one. It was developed on vice.