DEV Community: Benjamin Mahr

Introduction of myself and my blog thoughts-on-cpp.com

Benjamin Mahr — Sat, 11 May 2019 19:29:44 +0000

Hello everyone,
I was told it would be nice to introduce myself..... hmmm well how shall I do that.
OK, I'm a C++/Qt software developer (with a background in mechanical engineering) and head of software development at KISSsoft AG in Switzerland. We are producing a leading calculation and design software for mechanical engineering, especially transmission gearboxes. I'm mainly focusing on the development of numerical calculations for contact pattern analysis of gearboxes, but also responsible for the development infrastructure and leading the development team.

In my spare time, I'm writing on my blog thoughts-on-cpp.com about programming and software development in general. I'm mostly focusing on topics such as implementations of numerical methods. I would be happy if you sign up and follow my blog.

You can also reach me via:

Best regards,
Ben

Introduction into C++ Builds with Gradle

Benjamin Mahr — Wed, 10 Apr 2019 06:00:39 +0000

Posted on thoughts-on-cpp.com

Welcome back to a new post on thoughts-on-cpp.com. In today’s post, I would like to give an introduction to the build system Gradle and how we can use it to build native applications and libraries. Gradle is originally coming from the Java world, but it’s also supporting native build toolchains for quite a while. Gradle is becoming more and more popular in the Java world and is on a good way to rule out the old bull Maven. This is because of two features which we can also benefit from in the native (C/C++, Objective-C/C++, Assembly, and Windows resources) build world. These features are Gradle’s easy to maintain and very expressive Groovy (or Kotlin if preferred) based DSL, and it’s capabilities of dependency resolving via online and on-premise library providers (such as maven-central, Artifactory, Bintray, etc.) or local repositories.

Let’s start with a multi-project example we already know from my post Introduction into an Automated C++ Build Setup with Jenkins and CMake. I have just slightly changed the example hello world application. This time the main function is printing out “Hello World!” onto console using a shared library, called greeter. The Greeter class itself is utilizing the external library {fmt} to print “Hello World” onto the screen. If you’ve wondered about the Gradle directory and files, those are provided by the Gradle wrapper which facilitates us to build the project without even installing Gradle upfront.

The Gradle native build plugin is quite straight forward to configure. Every Gradle project needs a build.gradle file at its root directory as an entry point and one at each subproject. In most cases, we will do general configurations in a build.gradle file located at the root directory. But there is no need, it can also be empty. By default, Gradle is looking for sources in the directory src/main/cpp. For libraries, public headers are defined in src/main/public and in case they should be used only library internal (private) the default directory is src/main/headers. In case we define the headers also in src/main/cpp, the headers are treated as private as well. If we like to overwrite the default source directories we just need to define them according to this example. To be able to resolve dependencies between subprojects, we need to define a settings.gradle file which is including our subprojects include 'app', 'greeter', 'testLib'.

components.withType(ProductionCppComponent) { 
//By convention, source files are located in the root directory/Sources/
source.from rootProject.file("Sources/${subproject.name.capitalize()}") 
privateHeaders.from rootProject.file("Sources/${subproject.name.capitalize()}/include") 
} 
components.withType(CppLibrary) { 
//By convention, public header files are located in the root directory/Sources//include 
publicHeaders.from rootProject.file("Sources/${subproject.name.capitalize()}/include") 
}

As build definition of our root directory we just simply define IDE support for each subproject. CLion, for example, has native Gradle support, so importing Gradle projects works smooth as silk. Therefore our root build.gradle file looks like the following.

allprojects { 
apply plugin: 'xcode' 
apply plugin: 'visual-studio' 
}

The application build configuration is defined at the app directory starting with calling the cpp-application plugin which is generating an executable file which can be found and executed at app/build/install/main/{buildType}/{machine}. Project internal dependencies can be defined by the dependencies clause with the implementation of the dependency defined as a project and the given name of the dependency. By default, Gradle is assuming the current host as target machine. If we want to consider other target machines we have to declare them as we do in our example with the targetMachines statement.

The library build configuration is defined at the greeter directory starting with calling the cpp-library plugin and the type of linkage, which can be STATIC and SHARED. Gradle is assuming we want SHARED libraries as default. A bit special is the way of how we have to resolve the dependency to the header only library {fmt}. Unfortunately, Gradle is not supporting header only libraries out of the box, but we can accomplish a workaround by adding the include path to the includePathConfiguration of the resulting binary. All other dependencies can be defined as api, in case we want to share the external dependency api with all consumers of our own defined library, or implementation in case we only want to use the dependency api private with our own library. A good example can be found in Gradle’s example repository.

With Gradle, we can not only build applications and libraries, but we can also execute tests to check the resulting artifacts. A test can be defined by the cpp-unit-test plugin which is generating a test executable. In principle, we could use any of the existing big test libraries, such as googletest, but in my opinion, the out of the box solution is pretty neat and lightweight and can be extended quite easily with external libraries.

With this project setup, we can build all artifacts by the command ./gradlew assemble and run tests by ./gradlew check. If we want to build and run all tests together we can invoke ./gradlew build. In case we need a list of all available tasks provided by Gradle and its plugins we can simply list them including their description by the command ./gradlew tasks. At GitHub you can find the resulting repository.

UPDATE: Thanks to D. Lacase I updated the source set configuration section to customize the folder structure of a project.

Did you like the post?

What are your thoughts?

Feel free to comment and share this post.

Introduction into an Automated C++ Build Setup with Jenkins and CMake

Benjamin Mahr — Wed, 27 Mar 2019 07:00:12 +0000

Postet on thoughts-on-cpp.com

Welcome back to a new post on thoughts-on-cpp.com. This time I would like to give an introduction into an automated build setup which, based upon Jenkins and CMake, fulfills the following needs:

Building a ready to deploy release on every commit
Execution of all tests
Running static code analysis to track code quality
And easy to extend with automated deployment (CD)

For all the necessary sources, I prepared a GitHub repository. We are focusing here only on a technical part of an automated build process which is a prerequisite of a CI/CD (Continues Integration/Continues Deployment) process. It is quite a bit more necessary than just tools for a company to fully embrace the ideas behind a CI/CD process but with an automated build and test setup your on a good way.

The build, of a Qt and C++ based example desktop application, will be orchestrated by Jenkins declarative pipeline. The example application is based on a simple CMake project generated with CLion. As static code analysis tool, we are using cppcheck. Testing is done with my favorite testing framework Catch2.

In this post, I presume your already familiar with a basic Jenkins setup. If you’re not familiar with Jenkins, jenkins.io is a good source of information.

Jenkins consists of a declarative pipeline defined in a file called Jenkinsfile. This file has to be located in the projects root folder. The declarative pipeline of Jenkins is based upon Groovy as a DSL and provides a very expressive way to define a build process. Even though the DSL is very mighty because it is based on Groovy you can actually write little scripts, its documentation is, unfortunately, a bit mixed up with its predecessor, the scripting-based pipeline. For our example setup, it’s looking the following way.

The syntax is pretty straight forward. A Jenkinsfile starts always with the declaration of a pipeline block, followed by the declaration of an agent. An agent describes on environment our build should be executed. In our case, we want it on any environment setup, but it could be also a labeled or a docker environment.

With the options directive, we define that we want to keep the last 10 build artifacts and code analysis results. With options we could also define a general build timeout, the number of retries we allow in case of a build failure, or the timestamp for console output while running the build.

The parameters directive provides us the possibility to define arbitrary build parameters of the types string , text , booleanParam , choice , file, ** and **password. In our case, we use booleanParam to provide the user with an option to define which additional stages the user wants to execute in case of a manual execution of the project.

But even if those configuration possibilities of Jenkins are vast and very interesting, the really important part of the build declaration file is defined by the stages section with its stage directives. With an arbitrary number of possible stages, we have all the freedom to define our build process as we need to. Even parallel stages, for example, concurrent execution of testing and static code analysis, are possible.

With the first stage, “Build”, we are instructing Jenkins to invoke its CMake-Plugin to generate our build setup and resolving all necessary dependencies via a Vcpkg CMake file. Afterward, the build is executed with cmake --build . through the withCmake: true setting. User-defined toolchains are also no problem so we could have also defined several build setups with GCC, Clang and Visual Studio Compiler.

The other stages, Test, Analyse and Deploy, are again pretty straight forward. All of them have one notable thing in common which is the when directive. With this directive, we can control if a stage gets executed if the condition inside the curly braces returns true. In our case, we use the when directive to evaluate the build parameters we introduced at the beginning of this post. The syntax might be a bit irritating at first glance but after all, it does its job.

To get Jenkins executing our nice pipeline we just need to tell it from which repository to pull. This can be done via the project configuration. Here you just need to choose the option ‘Pipeline script from SCM’. If everything is set up correctly you end up with a smooth running automated build process. Even better, if you have configured Jenkins correctly and it has a static connection to the internet, you can connect Jenkins to GitHub over a Webhook. This means that GitHub will invoke a build every time someone pushed a commit to the repository.

To conclude this post I would like to point out that this isn’t THE BEST WAY to configure automated builds. It is one way of millions possible. And it’s the way which worked out pretty well for me in my daily work. I introduced an adapted version of this several years ago in our company and Jenkins is serving us great since then. One important fact of Jenkins declarative pipeline is the point that it’s versioned over the SCM as the rest of the code is, and that’s a very important feature.

Did you like the post?

What are your thoughts?

Feel free to comment and share the post.

Weekly Knowledge Candy

Benjamin Mahr — Thu, 21 Mar 2019 13:58:24 +0000

Postet on thoughts-on-cpp.com

Welcome back to a new post at thoughts-on-cpp. This time I will write about something different, not quite technical and C++ related. Well, not exactly. It’s a post about team education, about how to evolve the C++ knowledge of a team which is, in my case, not build up with computer science experts, but purely with domain experts (in my development team we are all mechanical engineers or mathematicians). You may ask, why the hell are they doing software engineering only with domain experts? This will be for sure another blog post, I promise, to talk about this.

I’m working in this company for quite a while, basically since I finished my studies of mechanical engineering. But have I’ve been prepared for the professional development of desktop applications? Well…… not really. Back in university, we had C++ seminars for about a year, and the fact that we have been taught C++ was quite new in 2008. If you have studied mechanical engineering before, you would have been probably taught how to code in Fortran 77, or if you’re lucky in Fortran 95. And basically, the level of programming in C++ was the same as it was in the good old Fortran days. No classes, no encapsulation, no C++ idioms, just pure procedural programming. They just exchanged the syntax and the compiler, that’s it. Clearly, the intention was not to fully educate us in the domain of programming, but I think it’s also a bad idea, if not a dangerous one, to give students such a primitive bunch of half knowledge. And that’s in principle what you get as programming background in classical engineering areas (electrical engineers might be on a higher level). You end up with a team in which C++ knowledge is very heterogeneous. From pure procedural programming with bare knowledge about the STL, to very experienced/self-educated people who are firm with advanced metaprogramming and memory management topics. So somehow there has to be a way to raise the level of programming knowledge for everyone. Not only the most proactive developers, but also the ones which are simply not able, for so many reasons, to raise their programming skills.

How Weekly Knowledge Candy Originated

One day I stumbled upon Jonathan Boccara’s blog Fluent {C++}. And there was one small page on the side, called Daily C++. Johnathan states that you learn the best while your teaching, and I totally agree with my own experience of teaching in seminars. So I thought it would be a good idea to somehow adapt his concept of Daily C++ to our needs and introducing it into the company. Many of his ideas work nicely for us. For example the short 10 to 20 minute presentations and fine granular topics which fit into the time frame. We just felt that having daily presentations, even such short ones would be too exaggerating for us. Once a week would be fine because, with only 17 developers, everyone would have at least a week to prepare him-/herself. To start we carried a list of topics together we wanted to introduce or deepen our knowledge. Not only C++, but also topics about patterns, established architectures, frameworks, tools, but well… mostly C++. We ended up with a list of around 20 presentations topics, such as RAII, Rule of zero/three/five, operator overloading, memory management, observer and factory pattern, and much more. We encourage the developers to pick a topic and prepare it to present in any way they like. That can be on a whiteboard, PowerPoint, purely code, or most often a mixture of several forms. The only requirement is that the topic is documented and self-explanatory. That way developers who haven’t been able to attend can read it whenever they like. The second and last requirement is that everyone should try to pick the topic he’s/she’s the most unfamiliar with. Picking the topic they have the weakest knowledge gives the developers the opportunity to learn and earn the most out of the weekly’s because it’s not just a simple repetition for them. Contrarily to Jonathan’s approach we always gather in a dedicated and equipped meeting room. We experienced an increase in attention and broader discussions afterward. Additional I think a dedicated room is not only helping to focus but also it’s much quieter. Noise can really be a big problem in large open-plan offices.

Let’s summarize the benefits of the Weekly Knowledge Candy:

Little easy digestible topics
Developers train their ability to give presentations and speeches
10 to 20 minutes focus helps to understand a topic
Every developer is focusing on his weakest topics. This way the whole team is gaining the most benefits.

Did you like the post?

What are your thoughts?

Feel free to comment and share the post.

Introduction into Logging with Loguru

Benjamin Mahr — Tue, 12 Mar 2019 06:00:11 +0000

Postet on thoughts-on-cpp.com

This time I would like to give a short introduction into a nice little library I just encountered. It’s called loguru and it’s a lightweight, Thread-Safe, logging library with an impressive good written documentation and human-readable output.

To use it all you need to do is to add a single header and source file to compile with. Unfortunately, that’s, in my opinion, also a drawback. Yes, it’s easier to install and usable in training, but it can’t be exchanged by whoever is operating the system after deployment. In such cases, where the operator wants to define how and what to use for logging, a generic logging interface (facade pattern), such as slf4cxx which is similar to its java pendant slf4j, would be preferable.

Loguru is supporting a various number of features, such as callbacks for logging and fatal errors, verbosity levels, assertions and aborts, and stack traces in case of aborts. It even supports {fmt}. Everyone who ever was used to java/spring log outputs will recognize its similarities.

As you can see it’s pretty straight forward to use. We are not only logging several messages on INFO verbosity level, but also a message in a named thread called “complex lambda”. If we wouldn’t have defined the thread name with loguru::set_thread_name(“complex lambda”), loguru would state the name of a thread with a hex id. The main thread gets its name by calling loguru::init(…). Because our small tool is crashing, loguru is printing us a stack trace which in my opinion is not as helpful as expected, but with ERROR_CONTEXT we get a little better output.

That’s it for now with this post. We have now a short introduction into a, until now, rather unknown, but promising, logging library. Loguru is not only capable of producing Thread-Safe and human readable logging messages but also provides a very simple and handy interface to use.

Did you like the post?

What are your thoughts?

Feel free to comment and share the post.

Using Pointer to Members on STL Algorithms

Benjamin Mahr — Fri, 22 Feb 2019 05:00:12 +0000

Postet on thoughts-on-cpp.com

Sometimes I need to execute an operation, like std::sort or std::transform, on a container of structs or objects using a lambda or function pointers which should take type defined criteria. Another scenario might be a global minima search of an arbitrary brane which could be described by a vector of 3-dimensional vectors. In such cases, we often use pointer to members.

This topic might be a piece of cake for every experienced C++ veteran. But I remember back in the days when I was a novice, I was really irritated by a piece of code which was using pointer to members, to do a special operation. I didn’t get what that piece of sh*t was doing and why it was written that wired. And even worse, it was neither easy to find documentation of that code, nor information of such “magic” it was doing on the internet.

So how might something like this look like? Let’s say we have a vector of complex numbers which we want to sort by either the real or the imaginary number. This is our complex type:

For sorting vectors, we would use std::sort of course and for vectors of primitive types, it’s rather simple to use. And indeed, it’s easy to use with complex types as well. Because std::sort is offering an interface which is taking a compare function object that has to fulfill the requirements of Compare:

Using std::sort for sorting according to real or imaginary numbers might then look like this:

The interesting point in the code above is the declaration of double Complex::*var (pointer to member of Complex of type double), in line 6, which is passed to the lambda over the captures clause. The lambda function is using the pointer by dereferencing it to a comparable type (in our case a double) in line 7. It’s then used by assigning it a concrete pointer in line 9 and 12 to steer the std::sort algorithm.

For me, such indirections are sometimes quite useful but not always. The biggest problem might be the readability for programming beginners. Also, there might be a better way to have the same functionality without pointers to members. I would be glad to hear any suggestions or feedback.

Did you like this post?

What are your thoughts on this post?

Feel free to comment and share the post.