testing

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.

Read Full Article

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:

  1. My God, it’s Full Of Stars: The n-body-problem series
  2. My God, it’s Full Of Stars: And then there was CMake

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.

Read Full Article