Hi, I'm Tomasz

In this post I’ll try to clarify some of the misconceptions about C++ which I often find in various code bases.

People have their habits

C++ is a complex language. Part of this complexity stems from legacy. With legacy comes source code which is often bad. Code that is difficult to maintain, which relies on false assumptions. These assumptions have been reinforced in programmers’ minds early on when the language was in its peak popularity (which was probably like 20 years ago) or (even worse) have been adopted from C world by people who still think that C++ is just C with classes.

/proc provides essential data about the operating system on which the program is running. Often there’s a need as well to alter system’s configuration using /proc files as an interface. Now, you may ask yourself, why should you care? After all, there are already well established solutions like i.e. procfs or containerd allowing for convenient dealing with proc files, cgroups… and I agree. Sometimes though you just don’t want to suck in a huge dependency like containerd and it’s much easier to write something smaller that is better tailored to specifics of the problem at hand. This is what I’m trying to achieve in this post.

What are method expressions?

Coming from a C++ background, I’ll allow myself to use a C++ example. If you know C++, Golang’s method expressions are very similar to member pointers. The code is relatively simple and even if you’re not a C++ enthusiast it should be possible to understand the intentions

Here’s a short C++ recap:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

class Foo {
public:
    std::string foo() {
        return "foo";
    }

    int bar(int i) {
        return i;
    }
};

using FooPtr = std::string (Foo::*)();
using BarPtr = int(Foo::*)(int);

int main(int argc, const char *argv[])
{
    Foo f{};

    FooPtr fooPtr = &Foo::foo;
    BarPtr barPtr = &Foo::bar;

    std::cout << (f.*fooPtr)() << std::endl;
    std::cout << (f.*barPtr)(123) << std::endl;
    return 0;
}

In C++, member pointers allow to obtain a pointer to either a member function or a variable. The pointer itself is disassociated from any particular class instance. Thanks to that, member pointers were often used as delegates. Nowadays these are superseded by lambdas or std::bind although the usage of the latter is rather discouraged as well. Right, but this is a golang post, isn’t it? Here’s how method expressions work in golang:

Why?

Well, it kind of happened by accident, if I’m honest. While working on a different project, where I’m building a set of utilities (assembler, disassembler, debugger, simulator) for a custom programming language, I needed a parser to create some basic CLI interfaces. I wanted to limit the amount of dependencies and thus didn’t want to reach for Boost’s program_options. Another reason is that I don’t really like it that much. program_options’s syntax is… weird, confusing and a bit cumbersome. It’s not something I can use without spending some time with the documentation.

It starts with “how?”

std::variant is a new addition to C++ standard library adopted from ominous boost libraries. Just as a reminder, std::variant is a type safe union with a very cool visitor interface, thanks to which handling its state is very convenient. The type itself wouldn’t be very special to me until I stumbled upon this sentence on cppreference

As with unions, if a variant holds a value of some object type T, the object representation of T is allocated directly within the object representation of the variant itself. Variant is not allowed to allocate additional (dynamic) memory.

Let’s write a calendar app

Recently I stumbled upon a very common interview question (I think it can be found both in AlgoExpert database as explained in this mock interview) and CoderPad examples database. The gist of the problem is that you’re asked to write a calendar app, which given two calendars will return a list of free time slots between the two. Each calendar is a list of meetings.

What are user defined literals?

This is a small feature added with c++11 revision which I think is super fancy. In short, you can define your own unit system when declaring variables and each literal’s value, prior to its usage will be put through the operator appropriate to the types and suffixes used. cppreference page describes everything in great details. This sounds a bit unclear but the examples will summarise everything, I promise.