Hi, I'm Tomasz

CMake has become a de facto industry standard as a natural ancestor superseding autotools. But is it actually an improvement? Personally, after spending signifficant amount of time with CMake projects, I’m inclined to conclude that no, not really. Below, I present why CMake sucks and why you shouldn’t use it for any of your projects.

Just as a disclaimer, I’m presenting my personal views here, which are very subjective. You’re entitled to have your own opinions. You have been warned :).

How to reverse a linked list?

Yep! This headline says it all. For some reason, for quite a while, this was (hopefully it’s no longer) a very popular problem given during technical interviews. Why that might be? Probably because it’s a simple problem to solve, interviewers don’t have to prepare themselves to use it and it has a couple of solutions so, it’s a good conversation starter about algorithms and performance in regards to time & space complexity. On top of that there’s possibility to follow up on the question, ask about detecting cycles in the list, cache friendliness, so on and so forth. But obviously, prior to solving the problem itself, the candidate has to come up with the implementation of the linked list.

Why Observer is so cool?

Managing complexity in large code base is all about decoupling. Observer is a perfect tool to do that. The Observed object has no idea about its observers, no dependency injection is required at all, as a result a loose coupling is achieved between two classes of objects where the only common part is the interface they agree upon.

First iteration

It’s a classic design pattern and I’m sure majority (if not all) of engineers know the details behind it, most of us implement it in a slightly different way, depending on the requirements and the code base we are working with though. Here’s my flavour of this design pattern.

Why signals are important

Signals are the simplest form of IPC in Unix-like systems. They are notifiers to the process that an external event has happened. As this is a system specific mechanism, there’s no portable C++ STL library providing support for signal handling. But it’s fairly easy to write one. First though a short introduction is required.

Signal disposition

Each thread in a process has a signal mask which can be modified either via setprocmask (for single threaded processes) or pthread_sigmask (for multithreaded processes). Every raised signal is checked against the mask. If it’s blocked, it’s residing in a PENDING state and it will be immediately handled once unblocked. If it’s not blocked, its corresponding signal handler will be called or the default action executed in case there is none. Of course there are signals which can’t be blocked or its disposition can’t be altered (like SIGKILL or SIGSTOP). In other words, pending signal is handled as soon as thread’s signal mask unblocks it. It’s also worth to remember that signals are not queued (aside from realtime signals - these are queued). Multiple subsequently raised pending signals will be handled as if a single one was raised.

Callbacks are a perfect way for clients to interface with an API abstracting an events source. How to design an API for such abstraction to make it unambiguous and easy to use? The simplest choice is functor injection, similarly as it is done in many places in STL (or even C stdlib by means of function pointers). Can we do better though? What are the alternatives available? In this post, I’ll try to provide a step by step overview of a design process for an imaginary HttpServer class.