## Page 2 of 3

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.

Welcome back to another exciting part of the n-body-problem post series. This time we are going to implement the Euler-Method to make the tests, we defined in the last post, pass. If you just dropped in or need to fresh up your memory see the links to the previous posts below. I also stumbled upon a very good presentation of the n-body-problem topic. Even if it’s quite mathy, it serves us as good background information.

Welcome back to the n-body-problem series. Last time we’ve been setting up our project structure and CMake setup. According to some helpful reddit comments, I adapted our CMake setup a bit, but I’m still not absolutely sure if the project structure, as it is now, will last to the end of the project. If you’ve missed any of the earlier posts, you can find them here:

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.

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. Read Full Article

Sometimes it seems to me that tools are getting too important. Don’t get me wrong, I really appreciate those little helpers modern IDE’s and their plugins are offering. For example if they’re suggesting to me a method might be rather static instead of const. Or not all paths of a lengthy, chained and nested If statement are returning something. Especially with legacy code those tools are very helpful.