C/C++

The run-time search path (rpath) defines paths to search for dynamic libraries when executing a program. It is a mechanism on Linux parallel to the LD_LIBRARY_PATH environment variable, which is another hint to find dynamic libraries. Usually, it is a good idea to make software which you built relocatable. This means that created binaries can be moved around and they still work after the location change. This includes the ability to still find the correct versions of dynamic libraries. One simple way to achieve this is by setting the rpath relative to the current location of the binary. In CMake this can be achieved like this: ...

If you are building multiple related software projects with a continuous integration server one important aspect is to be notified when changes in an upstream job break the build or tests for a downstream job. This involves knowing which exact build numbers of the upstream and the downstream job are involved. The Jenkins continuous integration server uses the notion of file fingerprints for this purpose. The upstream job is built by Jenkins and produces one or several so called artifacts, the results of the build process. The artifacts are archived by Jenkins and fingerprints (hash sums) for each artifact are created and stored along with the build number of the job. When the downstream job starts to build it downloads the (most recent) artifacts from the upstream job and uses them for its purposes, i.e. building and running the own source code. By comparing the fingerprints of the downloaded artifacts with the stored fingerprints Jenkins knows which version of each upstream job was involved in a build and can track which upstream build number broke the downstream job. Jenkins will only issue notifications if this fingerprinting mechanism is properly configured, triggering a build after another is not sufficient to receive these notifications. Moreover, the Blame Upstream Commiters plugin needs to be used and enabled for each downstream job or the global property hudson.upstreamCulprits (will this ever be renamed?) needs to be set. ...

I am currently evaluating the applicability and limitations of the Jenkins continuous integration server for C++ development. Besides several limitations which are mainly caused by the complexity of C++, Jenkins provides a solid basis for continuous integration of C++ projects. One thing which I was not happy with so far was the missing integration of open-source coverage tools for Linux. Here, Gcov can be used to generate more or less precise coverage reports for projects compiled with GCC. Unfortunately, Gcov itself does not provide tools to export the results in any common or even nicely readable format. Until now, the only working solution I found was to use the Gcov front-end LCOV to generate a HTML report. This report is nice to read but it cannot be tracked by Jenkins with the drawback that no trend report for the code coverage can be generated. Nevertheless, I’ve wrapped the creation of such a HTML report in a CMake function and worked with it so far. ...

I’ve seen this several times causing troubles: boost::shared_ptr<Foo> p(new Foo); boost::thread t(boost::bind(&Foo::method, p.get())) This prevents the livecycle management of shared_ptr or any other smart pointer to be effective in the thread. Hence, p may get destructed even though the thread is still active. Boost bind can handle smart pointers, so instead use the smart pointer itself as the instance argument for bind: boost::thread t(boost::bind(&Foo::method, p))

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. ...

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. ...

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: ...

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… 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. ...

Template Programming to the Extreme… Manchmal macht es echt eine Freude den Quellcode der BGL (Boost Graph Library) zu lesen. Hier ein paar Highlights: typename T::ThereReallyIsNoMemberByThisNameInT vertices(T const&); // The graph is passed by *const* reference so that graph adaptors // (temporaries) can be passed into this function. However, the // graph is not really const since we may write to property maps // of the graph. Spaßig sind aber auch die Compiler-Fehlermeldungen: ...

In der Java-Welt gibt es schon lange die sinnvolle Konvention kompilierte class-Dateien in einer anderen Verzeichnisstruktur abzulegen als den Quellcode. So eine eine Konvention hat viele Vorteile: Falls der Quellcode in ein Versionskontrollsystem eingecheckt wird (und das sollte er auf jeden Fall), müssen nicht umständliche Regeln zum Excluden der kompilierten Dateien geschrieben werden. Dateioperationen im Source-Tree (z. B. ein Aufruf von find oder grep) müssen nicht aufwendig um die kompilierten Dateien herumgelenkt werden Leider ist dies in der C++-Welt teilweise noch nicht ganz angekommen, deshalb hier ein kurzer Reminder, wie solche “Out-of-Source Builds” mit CMake gemacht werden können. ...