## Page 2 of 3

Welcome back to a new post on thoughts-on-cpp.com. In today’s post, I would like to talk about the floating-point model of the IEEE 754 standard. Before we start I would like to state that I’m neither a mathematician nor an expert on this topic. I’m just interested in this and I’m learning the best myself by explaining it to others. So feel free to leave comments about misunderstandings or other problems you see in the explanations of this post. As a reference I’m using the IEEE 754 standard and the book “Numerische Mathematik” which is, in my opinion, one of the best books about numerical calculation, but unfortunately only available in German. Read Full Article

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.

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.

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.

Because we want to exercise TDD, we somehow need to define some test cases first before we can implement our solver library. A simple scenario would be two points with an equivalent mass $M$, a distance of $r$ and no initial velocity and acceleration. Clearly we could do hundreds of different complex tests with it. But i would like to start with two very simple and specific tests, point masses accelerating and moving only in x- and y-direction sole. This way we can check that, at least the basis, assumptions, formulas, and implementations are correct.