In the beginning there where three build systems we where trying to support for QueryC++. These where bare bones Make, waf.io with a custom extension written by Steinwurf ApS, and finally CMake.

In this update. I mentioned that we we are reducing the build systems to only CMake and to my surprise (lol not!) some people wrote me that the choice was stupid. Some argued the case for Make, waf, and xmake, the latter being a system I briefly had considered. Others argued the case for Bazel Most arguments were very valid and most where things I had considered, but CMake still won. A thing I will say here is that there where some very compelling arguments for Bazel I had not considered. Although these did not make me switch QueryC++ to Bazel, they have made it so it is a build system I will explore more (spoiler it has something to do with Go).

Now why did CMake win? Basically it boils down to widespread usage and ease of use. CMake is, if you dedicate like 24 hours to it, easy to use, both for defining and setting up you own project and also configuring external dependencies. FetchContent plays a big part here. Both in terms of handling external dependencies, but also the ease with which we can make QueryC++ available to others. Additionally the fact that CMake is available for (almost) all platforms means that we easy can provide it to a large audience. A very huge plus.

Another positive of CMake is that I have seen examples of projects depending on both waf and Bazel adopt an approach that could make CMake based dependencies available in these projects, with relatively low effort. Again speaking to the benefit of CMake and its wide spread usage.

So basically this is why it won. Now we may switch in the future who knows. Maybe Bazel proves a better build system. But for now we stick with it.

Support for using QueryC++ via FetchContent

AND WE OFF!!! I finally had time to spend some time understanding FetchContent and how to make a package available. So now QueryC++ can be used via FetchContent. We are really excited about this as previously people have been copying the files by hand. But that ends with QueryC++ 4.0!

For a small teaser you can test it with the small example below. First a very simple C++ program, note that the valid function will not be available in the final release of QueryC++ 4.0

#include <querycpp/querycpp.hpp>

#include <iostream>

int main(void) {

    std::cout << querycpp::valid() << "\n";
}

Followed by the CMakeLists.txt file.

cmake_minimum_required(VERSION 3.18)

project(test_querycpp VERSION 4.0.0 DESCRIPTION "Test QueryC++" LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED True)
set(CMAKE_CXX_FLAGS "-Wall -Wextra -O3")

include(FetchContent)

FetchContent_Declare(
    querycpp
    GIT_REPOSITORY https://gitlab.com/looopTools/querycpp.git
    GIT_TAG querycpp_four
)

FetchContent_MakeAvailable(querycpp)

add_executable(t main.cpp)

target_include_directories(t PRIVATE querycpp fmt::fmt)
target_link_libraries(t querycpp fmt::fmt)

This can be compiled by the following series of command on Linux and macOS where CMake and clang++ or GCC++ is installed.

mkdir build
cd build 
cmake ..
make 

These steps will automatically download QueryC++ and make them available for your code using FetchContent.

If you are wondering why we reference fmtlib, it is because it is a dependency of QueryC++. At least it is until compilers start supporting format truly.

I CANNOT STRESS ENOUGH: QueryC++ 4 is not ready for production use and this only servers as an example.

./Lars

January is closing and I have some happy updates on QueryC++ 4.0, that I want to share.

In my last post I talked about how I wanted to be able to work on QueryC++ at least once a week. I have actually almost been able to keep on top of this. With one exception, which was rectified by working two days in a row the week after. The progress I make even during short sessions are good and I think it was the “spring cleaning” the project needed. I am getting this changes reviewed by a third-party and they seem to approve.

The only thing we are currently in disagreement about is my usage of && and || for and and or operations specifically. We are currently arguing what the best solution is for this. I will open up a discussion issue some time during February to get a broad perspective on this.

You will also find that the tests and build CI pipelines are now running as indented, which I am very pleased about. This now means that as long as I write tests, I will catch if I break something. A thing I am really happy about.

Next, concepts are a feature of C++20 I have eyed with some desire for quite a while and finally found a great application for it. You can find this in the column.hpp header. I am really exited about how well this integrates with the code and makes my life a lot easier. I implemented and tested it today and I am very happy with result.

Finally, documentation using mdbook. Although I have not had time to write so much documentation yet, it will be a priority during February, I have setup the mdbook part of the repo. I hope this will provide a super easy to use documentation for QueryC++ and I hope we can find a great way to keep it up to date.

I you want to follow along with the development you can check the QueryC++ 4.0 branch here.

./Lars

New year, new ideas, and a fresh start. As I stated in my last post Wrapping up 2023, honesty, and looking forward to 2024, I have not had the energy nor mind to work on QueryC++. But this will change starting from now. QueryC++ will become a priority of mine and I will try to work on it a least once a week in the beginning of 2024 and then hopefully slowly ramp it up. I have big plans for 2024.

First of, let us get one of the bigger things out of the way. I want to take advantage of some of the features from C++20 like std::format, therefore I have decided to bump the version number of C++ for QueryC++. I see this as a major change and therefore we bump the major version number of QueryC++ also.

Next, I have had some complains that QueryC++ is not header only. Not huge complains but actually from more than five users. Therefore I am have been considering for a while and I think now is this time to make this move. I honestly think it will be a good move! But it also requires a major version bump so I will bundle it with the C++20 version increase.

Then we have all capitalised method names to use SQL commands such as and. However, users and reviewers of the code has been annoyed with this and therefore instead we will start to utilise operator overloading! This is something I am very excited about and it will make the code more C++ like to read a think I am all for!

Another request have been to replace std::string with std::string_view this is a good idea in many cases. However, in certain places I will keep std::string. But it is coming during this year.

Now, we will move on to the “fluff” around QueryC++. First of integration testing. As you may have seen we have some integration testing with PostgreSQL. However, it is not nearly enough and we need to make this an integrated part of our CI workflow. The intent here is also to make it part of our CD. Both to reduce the possibility of bugs in production and also to prove query C++ is a very viable tool for the job.

Then, there is documentation. It has been a little all over the place, sorry about that. But that ends in version 2024! We will create a book based on mdbook an amazing tool created by the Rust programming language team. We will use this to create much better documentation and hopefully be able to provide you with an amazing and detailed resource for using QueryC++.

All of this will not happen over night. All of it will be bundle into QueryC++ v4.0.0 It is my goal to have this out by latest end of Q2 this year. I hope you will follow along on the journey.

./Lars

Hello all.

This is the first time I have decided to do a year wrapping up post and there are a few reasons for this. Which I hope will become clear throughout the post.

First of I do not have a full statics of how many actually read my blog. But I can see that the traffic is increasing for certain posts. So thank you to all whom are reading and sorry for not posting more regularly. I hope to be more consistent in the new year with a least one post a month. But we will see if that will happen.

Now let us talk QueryC++ for a little bit in my post [QueryC++] Status Update and Apology, I talked about why the development has not advancend so much. But this post was back in may, so why has more not happened. Well first of all it has, I just haven pushed it to the repo, more on this later. But another factor has played in a lot. I work as a Software Engineering Consultant and I really like the consultancy through which I work.

However, now the bad part. Earlier this year I was assigned to a customer which I was really looking forward to. The project was interesting and I saw a lot of potential. But after I week I honestly could not wait to get a way from this customer, for reasons I cannot speak about publicly. Yet I can speak about what this (for me) very painful period at the customer result in. Quite simply put it resulted in extreme stress, panic attacks, inability to relax, and other less pleasureable side effects. Basically things I got over four years ago. All the work I had put into getting control over my stress in the last decade or so came crumbling down. It left me extremly drained and beaten down.

I enjoyed (enjoy) solving leetcode puzzles. Yet the stress beat me down so bad that I did not believe in my own skills and I found that I could not even start a leetcode puzzle. Due to the fact that I did not beleive I could complete it anyways, even the easy ones. It was not good.

This spilled into other aspects of my life. I no longer wanted to pay Warhammer why bother I sucked anyway and it also resulted in me being unable to work on QueryC++. I should have been more open about these issues, but I simply could not. Bascally the only at home hobby I still retained was baking as that felt like the only thing I could not fuck up.

Now 2024 was all a bad. It was actually really good if I look at it overall. I met my in laws for the first title. My girlfriend got the new title of wife. I mannaged to get back to painting Warhammer and reading. But most importantly, I started realising that my job is not everything and that it is okay that I take vacations. This I have taken full advantage off, which has helped a lot.

This alone make me feel like I go into 2024 much strong than I was. It also makes me believe that 2024 will be the year where I finally get more time to work with QueryC++. Additionally I have another project going on the side which I hope I can reveal more about in Q2 of 2024. But we will see how well I will follow my own plans.

Best wishes for a happy new year.

./Lars

In this post I will discuss something a little different and a thing I maybe will start to talk more about on this blog. And it is miniature painting.

I really love painting miniatures but have been out of the game for a while. I stopped when I was roughly sixteen years old and started picking it up during COVID lock down again. So a little over fifteen years later. I am far from a pro painter and far from good… So I will not share pictures yet. But I still want to share some of my thoughts on paints, tools and miniatures as I learn a long the way. So let us get going.

In the blog post I will talk about two miniatures from Reaper Miniatures. The Gnoll Warrior and the Warg. I purchased the Warg first and the purchased the Gnoll. But lets start with some common things.

First of the miniatures are relatively cheap and very much so compared to Games Workshop (shock I know), I paid 39DKK (5.23EUR) for the Warg and 27DKK (3.62EUR) for the Gnoll. That is pretty nice for someone like me who just needs to get back into painting and needs some minis to train on, before moving to more complex (and expensive) figures. Also buying just one mini gives you the option to test out if it is something for you and you will not need to buy an expensive Games Workshop figure. So that is a big plus.

Next, my first issue with these figures. The package says “Ready to paint - No priming necessary!”. That is literally bullshit. I did not prime the Warg and it was not fun to put down the first base layer of paint. I used a Citadel base brush and a Citadel Layer brush to apply my first coat of white, it was an absolute pain in the ass. Here I compare to Games Workshop and resin 3D printed minis I have painted lately. In extension the package say “Spray primers are not recommend for Bones Miniatures” well I tried it on the Gnoll and it work so much better than what I did on the Warg. Now, I will not recommend that you use a spray primer when the package say not to, so if you do it, it is your problem.

Then, we have the quality. Here I am keeping in mind that the figures are significantly cheaper that Games Workshops, but I am have in the back of my head the quality of home 3D printed resin figures I have painted. For the Warg the overall quality is really good, with the exception of a tiny spot on the tail that looked like the plastic kind of melted together. I did not realise this until I started painting. The mini feels really solid with the exception of the include base, which feel wobbly where it attaches the wolf to base and it can bend a little. This is a tiny bit disappointing as I haven seen resin prints that is much more stable. However, overall I really like this minis quality

Then, sadly, there is the Gnoll. I am honestly not fully sure where to start with this mini when it comes to quality. I will give it the slight benefit of doubt and say I may have gotten one from a bad run. So first of all the mini has a flail. When I picked up my Gnoll in the store I picked the one where the flail was not bend into the face of the mini, here we are talking while still being protective packaging. Then when I unwrapped it I realised the chain of the flail was so soft I was honestly scared that it would break during painting. It did not but I was still scared. then I started to inspect the overall figure. It is so soft that an nail easily makes an indent in the figure and I accidentally damaged the mane of the mini a little bit because of this. Then there is a similar issue with the base as with the Warg. However, here the problem is even more evident as the base is more flexible and the ankles of the mini is very wobbly. I was more afraid these would break compared to the flail. This softness was there be fore I primed it, so it is not the priming that damaged the figure. If this was not enough then there are a couple of sculpting issues, where the picture to the right shows the most sever one. Half the left should is missing. In the top it is a clean cut and then in the bottom of the shoulder there is some texture that indicates fur. It looks like a miss print and I really hope it is. If I compare this to resin printed minis this is low quality. Although it is still far from the worst I have seen. But then based on quality would I recommend it? Well… Actually yes and here is my reasoning. If you like me do not plan to play games with the mini and will not move it often. Then I see absolutely no reason to train painting using this mini. It is perfectly fine for that.

Finally, and to me most important right now, paintability. I mean, if you ignore the whole idea of no priming then this is awesome figures to paint. The Warg has a lovely texture for hair and has a really cool pose. I only had one issue with the Warg and that was it was difficult to dry brush for some reason I could not really figure out why. It is a technique I have not really had any problems with in the past. So I am not sure what went on here. The gnoll is really fun to paint, when you get more sure it will not break. The shield has a nice believable wood texture and the armour and leather straps a nice. I found the toes a claws a little challenging to paint, but I will say this is more on me than the mini.

Now would I over all recommend these two minis? Honestly, it depends. Do you already have a resin 3D print (I do not) or do you know someone who can print for you (I do), I am actually not sure. There are quite a few sites where you can get print files for free or for a small amount of money and then print the figure (slightly) cheaper than what I paid for the Warg. With the final product will have a better quality, in my experience. If this is the case for you, then I would recommend this direction over the miniatures I have purchased here. But if you do not have this option, I would say it is a good solution for you who are looking to just pain and nothing more.

Finally, I would like to say that I have not tried all of the (amazing looking) figures from Reaper Miniatures, but I might be a little reluctant to spend money on them after the Gnoll.

./Lars