Hi, I'm Tomasz

Let’s suppose that you’re working with a virtual interface defined as follows:

1
2
3
4
5

struct I {
    virtual ~I() = default;

    virtual void process(int) = 0;
};

Now, let’s have a class A that implements this interface:

1
2
3

struct A : I {
    void process(int) override {}
};

So far so good. Now, let’s say you want to add an overloaded version of process in class B. This would look like so:

1
2
3

struct B : A {
    void process(std::string) {}
};

An attempt to use this class’s original interface like so:

zmq_poll is used to monitor multiple sockets for events. The API is very simple. zmq_poll takes a pointer to an array of zmq_pollitem_t structures, the number of items in the array, and a timeout value in milliseconds. Each zmq_pollitem_t in the array acts both as an input and an output. The input part is used to specify the socket to monitor and the events to monitor for. The output part is used to report the events that occurred on the socket. Here’s how you’d typically use zmq_poll:

Recently I’ve been doing a lot of template meta-programming in C++. As we all know, when writing a class or a function template, the definition must be in the header file. This is because the compiler needs to see the definition of the template in order to instantiate it. There are some exceptions to this rule. The restriction doesn’t apply if you explicitly instantiate the template in the source file (and of course limit the template’s use to the set of types you’ve instantiated it with). But there’s one more exception, which I think, is not very widely known - full template specialisation.

I was initially sceptical about just task runner. I wasn’t really convinced that it’s a tool solving a real problem and thought of it more as a gimmick. Finally, I decided to give it a try to form a more informed opinion. Below are some of my observations.

It’s just a command executor

In essence, that’s everything just is. You create a justfile in which you define tasks. Each task is a set of steps. Each step is executed in a separate shell instance. It’s possible to define dependencies between tasks. Here’s a basic justfile example:

C++ is an old and complex language with a lot of legacy and dark avenues where problems lurk. Aside of very obscure and arcane problems you might experience when working with C++, there’s a set of very common ones which eventually everyone will come across. So, let’s have some fun and name a few.

Most vexing parse

Most vexing parse is a declaration ambiguity in the language. What might look like a variable declaration, really is a function declaration. Here’s an example:

Recently, while exploring Python’s code base I stumbled upon these cryptic lines in its build system. I’ve never used profile guided optimisations before so, that led me into a goose chase to learn more about them. This post is about how to use clang to employ these optimisation techniques in practice and how much performance gains can be achieved (if any).

What’s profile guided optimisations (PGO)?

The main principles behind PGO can be described as:

I’ve recently watched a video from TheCherno about visual benchmarking.

In short, he’s using a simple timer class in C++ to collect execution timings of his code and then generate a json file containing profiling data which can be visualised using chrome tracing.

He’s using a set of macros to automatically get function names when instrumenting the code.

This gave me an idea to actually use gcc instrumentation to inject the timers globally into the entire program and collect the data without having to manually instrument the code. Additionally, I’m gonna experiment with LLVM Xray instrumentation which makes the whole process even more simpler.