Today’s post is gonna be a short one. I’d like to recommend a framework which I used personally on a number of occasions.
Golang comes with a great environment and a set of tools. Tests are first class citizens. Why would you need additional framework for your tests then? Purely for convenience.
is is a mini framework, at the moment of writing this post, the API is comprised of four functions:
C++17 has brought some interesting additions to STL algorithms. One of which are execution policies. This is a set of tags that some STL algorithms accept as first argument (there’s an additional overload provided), instructing how container elements will be accessed and processed. C++17 added three distinct execution policies and one more came along with C++20. As of now, the list contains the following:
class sequenced_policy,class parallel_policy,class parallel_unsequenced_policy,class unsequenced_policy.The description of these policies can be a bit intimidating and unfamiliar at first glance. Let’s take the description for parallel_policy:
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 :).
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.
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.
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.
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.
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.