Speiseplan gestern in der Mensa:
Frühlingsröllchen, Chili-Pfeffer-Dip, Reis, Eisberg mit Möhren, Kokosquark
27.08.2010
Menü Titanic
20.08.2010
Ignoring Warnings from System Headers
Compiling C and C++ code with the highest warning levels is a good practice and helps spotting potential errors. For GCC the flags
-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)
9.08.2010
Unused Parameters in C++
Just some quick thought on how to handle compiler warnings about unused parameters in C++ code. While these warnings are helpful most of the time, sometimes you simply have to ignore a parameter that is required by an interface definition. Then you got three solutions to remove the warning:
- 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.
- 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.
- 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.
CMake doesn’t provide a dedicated way to install header files (except for mac). What I wanted to do was to install all headers of my project using the same directory structure as in the source tree. This isn’t as easy as it sounds. Assume you have a list of header files:
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)
13.04.2010
Using googlemock with the Boost Test Library
googlemock is a framework that allows generating mock objects for unit tests. I’ve decided to use this framework as it looks wells designed and maintained. The default is to use googlemock with Google’s unit testing framework googletest, but as I was already using the Boost Testing Library, I was searching for a solution to use googlemock in Boost Test. Fortunately this isn’t to hard to accomplish. You only have to create a TestEventListener that forwards all results supplied by googletest to the Boost Testing Framework:
#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)
12.04.2010
Doxygen Support in Eclipse CDT
Since a long time I was wondering why CDT, the C++ support for the Eclipse IDE, doesn’t have a decent support for highlighting and creating comments in the Doxygen format. Today, while searching for customizable code templates per project, I found the setting to enable Doxygen support. It is located in the project properties at “C/C++ General”. Not that intuitive…
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.
3.04.2010
Flickr machine tags for lenses
I’ve added a simple script to the software section that allows adding machine tags to photos on your Flickr photo stream based on exif information found in the image. I use this script to tag photos with lens information but in general it can be used for every type of tag to add that can be deduced from the exif information.
8.11.2009
C64 Revival – Pong Evolutions
Last year at university I was participating at course for game development on a C64 machine. Let’s get back to the 80s… Most of the time it was fun. But it was also challenging for us to develop thousands of lines of code in Assembler. Something completely different to the object oriented programming I do normally.
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:
The game should be playable on every modern C64 emulator or the real one. It was developed on vice.
In die aktuelle Linux-Version von Google Earth (5.1.3506.3999) scheint sich ein recht übler Bug, was das Verarbeiten von Tracks angeht, eingeschlichen zu haben. Bisher hatte ich nie Probleme, GPX-Dateien von meine GPS zu Laden, doch als ich es heute zum ersten Mal mit dieser Version versucht hab, war mein Track nur eine senkrechte Linie auf der Karte. Auch eine mit GPS-Babel nach *.kml konvertierte Variante hatte dieses Problem. Was hingegen funktioniert hat, war das Erstellen, Speichern und erneute Laden eines Tracks in Google Earth. Ein Vergleich meiner KML-Datei mit der von Google Earth selbst generierten hat einen netten Fehler aufgedeckt: Google hat wohl etwas zu viel i18n oder l10n gemacht, so dass beim Erstellen und Laden von Dateien das landestypische Dezimalzeichen (also mit deutscher Locale ein Komma) benutzt wird. Laut GPX- und KML-Spezifikation ist es natürlich totaler Müll, Koordinaten in der Form 52,xxx zu benutzen. Folgender Trick hat Google Earth dann davon überzeugt doch einen Punkt als Dezimaltrenner zu benutzen:
LANG="" googleearth
So startet Google Earth auf Englisch.
16.08.2009
