This post will try to answer a simple question: when is it legit to call
std::move twice on the same object? While some people would say “never”,
I actually think the answer is more subtle. To capture these subtleties,
this article will introduce the concept of move-independence, which I
believe to be a useful notion to keep in mind when writing generic libraries.
Recently, I’ve been looking at ways to index into parameter packs with as little compile-time overhead as possible. This is not a new problem, and we know of several metaprogramming techniques to achieve this, some of which offer pretty good compile-times. Most of these techniques are also well documented, for example here and here. So, why write an article about this well-covered topic? Well, I recently decided to cheat and modified the compiler to see how fast we could possibly be. This article summarizes what I found.
I really love GitHub and their product makes my life much easier. Heck, I’m even writing this post from Atom! But their GitHub Pages redirection is truly broken, and I need a solution. Here’s my problem.
The goal of this post is to introduce sum types and product types from a
very high level perspective, and to try and derive an intuition for what
the meaning of tuple<> and variant<> should be. The mathematics in
this post are purposefully kept a bit vague, because being more formal
would make the post heavier.
This (first!) post will present my current understanding of how laziness can
be represented as a Comonad. The interest of seeing laziness as a Comonad
appeared while working on a C++ metaprogramming library called Hana as
a possible generalization of the eval_if construct from the MPL library.
More generally, anyone trying to implement a domain-specific language with
a notion of branching inside a strict language (as opposed to non-strict like
Haskell) will have to design a system to emulate laziness, in order to
evaluate only the branch that was picked by the condition. This post is
an attempt to describe such a system using the notion of Comonad.