I’ve been away from this blog for a while (nothing new) but I’m back and now we got some tiny gnomes to help us write text or even code.

In fact, those gnomes are the main characters for this new post as we’re going to talk about vibe coding (yes, yet another vibe coding blog post). Along the way, we’ll look at the dual personality of programmers, the long history of programs writing programs, why natural languages are a poor fit for describing code, and where all of this might be heading.

Context, foreword, introduction …

I won’t split hairs on vocabulary: vibe coding, AI assisted code writing, whatever you call it, all of this falls into the same trend: leveraging new AI models’ ability to work with code.

Now, for more context: I am a software engineer but I have been a computer science teacher (and programming was one of my main lectures for years) and I have been writing code for decades (I was about 8 or 9 years old when I wrote my first lines of BASIC on a zx81 in the mid 1980s). The biggest impact for today’s topic is that writing code is something natural for me, to a point where it’s sometimes (even often) easier to write the code than to explain what it should do. When I was building my programming lectures, to cover a new topic, I was usually starting by writing code and then derive my teaching materials from it.

But we are in 2026, and I work as a software engineer, and as such, ignoring AI tools is no longer an option. I, too, have my gnomes working for me everyday, I am OK with it, I can’t even say that I don’t like having them around. Now, we are in a transition period, and it’s interesting to think about it, look at what we get from it and try to identify the traps on the road.

To make sense of how we react to all this, it helps to look at who we are as programmers.

The geek and the engineer, the dual mind of a coder

Disclaimer: I have no degree in psychology or whatever social science. I’m an engineer but as I said I’ve been a teacher and as such, I’ve spent a lot of time trying to understand the mechanism and relationship to code in my students and by extension to my colleagues.

Across the years, I’ve come to the observation that software engineers usually have a mix of two personalities: a geek and an engineer.

The geek is the passionate programmer, the guy that writes code just for the pleasure of doing it. This is the part of us that gets excited by new programming languages, the part of us that pushes us to write smart and elegant code for the beauty of the result. This is also the part of us that gets highly opinionated on tech topics at the expense of productivity and pragmatism.

On the other side the engineer is the professional guy who wants to deliver. Writing code is only a way to get the job done. A good engineer should not waste time on writing the best code, the goal is to bring a solution that meets the expectations and relevant choices are those heading in that direction.

I believe, most of us are a mix of a geek and an engineer. I also believe that both can bring value to our job. Pure pragmatism can make mistakes in the long run, while over enthusiasm may lead to tunnel vision on the wrong things, but combine them and you can get a very efficient software engineer. Of course, it could also lead to disastrous results …

Back to our topic, the geek and the engineer have a lot to do with our relations to those AI stuff. When I first read The Unreasonable Effectiveness of Recurrent Neural Networks, I was thrilled (geek side) by the part where the RNN is generating LateX or C code, and even today after using assistants for a while, I’m amazed by some results. At work, the things I gave to my gnomes were all those long and repetitive tasks on which we waste so much of our time (probably the engineer side, pushed by the geek).

But the geek persona is also the one complaining the most about vibe coding. Afterall, where is the fun if we let the gnomes write the code for us!

On this topic, there is an excellent blog post by Sarah Dayan What’s left when agents write better code than you.

I won’t go in that direction. You can do vibe coding for boring parts and use your time to focus on interesting bits, this is where the fun is. In fact, I think that the geek in us has more to gain than the engineer.

Our geek and our engineer have more to do with how we react to those new technologies than with what we will do with them. The engineer shrugs and asks “does it ship faster?”; the geek crosses their arms and asks “but where is the craft?” Understanding which voice is speaking helps us sort the signal from the noise.

And with that lens, let’s look at the bigger picture.

The long story of programs writing programs

One of the privileges of being old, is that you’ve always seen it before …

So, our gnomes are only the last incarnation on a long list of programs writing programs. Some were successful (as far as I know, we still use compilers) and some far less so (where is Rational Rose now?).

Looking back at the emergence point of those technologies, you can see that people always reacted in a similar way: some were excessively enthusiastic while others rejected them outright. I’m not old enough to remember when the first compilers were introduced, but when I was a student, we were still discussing the benefits of using compiled languages over writing assembly. That’s probably why I was so interested in programming language design and compilers (and I’m still into it).

I can’t tell if there’s a pattern of successful tools, but there’s a trend that I want to dig into. When I look at these technologies, they seem to split into two big categories.

So, when it comes to programs writing programs, we can class them into: those that try to be userfriendly and those that abstract technical complexity while remaining technical.

In the first class, you will find graphical UI to build software without writing code, products that produce code out of specifications or modeling and so on.

On the other side, you have programming languages and their compilers, parser generators, templating engines, preprocessors …

And as far as I can tell, almost all userfriendly tools had a short life. They may have had some success, but they did not stay. On the other hand, languages created in the 1970s or 1980s are still being used widely and are still part of the top languages.

In which category do I put vibe coding tools? Surprisingly, the answer is not straightforward. If you consider the archetypal use case where a complete newbie prompts some AI tool, asking something like “build my website for me”, then we’re definitely in the userfriendly class.

But that use case is broken. There is this 80/20 rule, that essentially says that our newbies will be able to get the first 80% of their project and then they will struggle with the remaining 20% as it requires deeper understanding of software building.

In fact, if you look at how we are using those tools, you will see patterns that are not very different from what we’ve been doing for decades. Most of the discussions I’ve seen are not really about what to put in the prompt, but how to control the process: how do you enforce structured and reproducible behaviors? Think about it: we write rules files, configuration files, structured prompts, we set up hooks and checks – we are building toolchains around our gnomes. Somehow, the gnomes start to look more and more like compilers, code generators and other transpilers and less like the userfriendly click-click tools.

And that observation leads to a deeper question.

Are natural languages suited to describe programs?

If your code needs a comment to be understood, it would be better to rewrite it so it’s easier to understand. Rob Pike, Notes on Programming in C

This is not a new problem. Formal disciplines have always struggled with natural language. Consider this passage:

If a first magnitude and a third are equal multiples of a second and a fourth, and a fifth and a sixth are equal multiples of the second and fourth, then the first magnitude and fifth, being added together, and the third and the sixth, being added together, will also be equal multiples of the second and the fourth, respectively. Proposition 2 from Book 5 of Euclid’s Elements

Take some time to process it. Got it? This is a(x + y) = ax + ay. Once mathematicians introduced symbolic notation (you know, +, -, =…), they never looked back. The symbols are not just shorter – they are precise, unambiguous, and scannable.

Programming faces the exact same issue. I am back with my teaching experience, but this time on algorithms. There’s a classic question that comes when building an algorithm class: how do you write algorithms?

Usually, the reasoning goes:

• algorithms don’t depend on implementation language, so you describe them with natural language;
• but then it becomes messy and unreadable, and even misleading;
• you add some structure to the text, then add more …
• you end up with something that is almost code, not exactly, but still.

At Epita, while I was doing the programming class, I was also teaching assistant for the algorithmic class and when I started, we were using a form of pseudo-code in French. But this pseudo-code was so formalized that I’ve been able to write an interpreter without the need of any further clarifications. In lots of papers presenting algorithms, you will find pseudo-pascal (or similar) code blocks. Those are way more readable than attempts in natural language, precisely because they borrow the structure and precision of code.

Let’s see why. Here is an algorithm described in plain English:

We want to compute the lower integer part of a square root of an integer n. We define our candidate root r and initialize it with n. Then while r is greater than n divided by r, we replace r with the mean of r and n divided by r. The final value of r is our result.

Now, the same thing as code:

unsigned sqrt(unsigned n) {
	unsigned r = n;
	while (r > n/r) {
		r = (r + n/r)/2;
	}
	return r;
}
// Yes, this code can divide by 0. This is an example.

I’m not saying that, given that code, you’ll immediately see that we’re computing a square root, but admit it (if you read code) reading the text was painful. And you know what, it was painful to write too.

Equations, algorithms or programs need precision and unambiguous descriptions. But we also want them to be concise, clear and straightforward. Natural languages are not good at this; symbolic languages and programming languages are designed precisely for this. And this matters for vibe coding: the more precisely you need to talk to the gnomes, the closer you get to writing code anyway.

Vibe coding or not vibe coding?

Let’s put an LLM in my compiler …

So, vibe coding or not? Both. The question isn’t whether to put the gnomes to work, it’s how they fit into the way we build software.

If I were to imagine the future of software engineering, I would see a convergence between coding assistants and regular development tools, just like IDEs, compilers, linters and others already work together to help you on your tasks. This kind of convergence is asymptotic, it never ends – and that’s fine.

Where I think things are heading:

• Chat-like interfaces are good for planning, launching tasks, asking questions and automating plumbing;
• Programming languages should continue to evolve towards less boilerplate, less verbosity;
• Coding assistants should integrate more structured configuration mechanisms (how many times did you ask claude to run the checks before committing code?)

In short, the gnomes will get better when we stop treating them as magic oracles and start treating them as what they are: another layer in the toolchain.

The cost of entry

Now, I have some concerns. One in particular keeps me up at night: the price.

Running vibe coding tools has a cost, and it’s not cheap. When I was a student, with an old computer and a Linux distro (or FreeBSD, or OpenBSD …) you were able to write code and contribute to any open source project. It was even possible to do it without an internet connection as long as you could access it from time to time. The barrier to entry was essentially zero.

That is changing. If effective coding increasingly requires AI tools, and AI tools require paid subscriptions or expensive hardware, then we are building a paywall around software development itself. There are attempts to provide models that run on your own hardware, but let’s be realistic, you need an expensive setup to do so – it’s not working on your average laptop. This could quietly reshape who gets to participate in open source, and that worries me.

Teaching programming in the age of AI

The other concern is education. How do we teach programming in this world? What’s the risk of having new engineers that are not able to write code by themselves? If students learn to prompt before they learn to think in code, do they ever build the deep understanding needed to debug, architect, or reason about systems? I don’t have an answer yet, but it’s a question worth taking seriously.

Final words …

I wrote this one shot, which hasn’t happened in years. I will save it twice (to keep the original) and run some AI assistant on it to fix my poor English and improve my prose!

This is a glimpse of where my thinking stands today. There are far more things to explore – we’re just at the beginning of the journey. If you haven’t tried putting the gnomes to work, do it, it’s still fun. And if the geek in you resists, remember: even compilers were controversial once. The engineer will come around. The geek might even enjoy it – after all, gnomes are kind of cool.

Variadic templates

Parameters pack are the way to make template variadic, that is defining template with an open number of arguments. The syntax is sometimes a bit disturbing at first, but once you understand it, it could really useful.

So let’s start with a naive and basic example, just to see the syntax in action:

template <typename ... Args>
void example(Args ... args)
{
    std::cout << sizeof...(args) << std::endl;
}

So, it applies to templates as I said, we start by defining a variadic list of type parameters Args. We can now define a list of parameters to our example function, args. We can do a lot of things with it, but just for the example we will use sizeof...() the version of the operator sizeof() to get the size of the parameter pack.

What we can do with args ? Almost anything we want, but we need to either have a uniform operation to perform or we should play with recursivity to decompose the parameters pack.

Let see an example using fold expressions, fold expressions are one way to use parameter packs. They basically let you apply uniformely an operation a bit in the same spirit of reduce or fold in functional language.

// Example from cppreference
template<typename ...Args>
void printer(Args&&... args) {
    (std::cout << ... << args) << '\n';
}

This function will print all its arguments and close the output with a new line. The syntax (std::cout << ... << args) (parentheses are part of it) expresses the unfolding of args, the expression is repeated with the content of the pack in place of the ... by repeating the operator between each elements.

But let’s have a look at the recursive approach.

Recursive decomposition

Templates are in essence functional, and thus we must adopt functional idioms. We can play with parameter packs like we would with list in functional languages. We will decompose cases with at least one for the empty pack and one for the recursion.

As a matter of example, let’s build print function similar to pyhton’s print (a very simplified version). This function will takes arguments and print them separated by space with a new line at the end. A bit like the previous example, but in a more subtle way.

First, we need a case for the empty pack:

void print()
{
    std::cout << std::endl;
}

Next, as we don’t want a useless space before the new line, we need a case for a lonely parameter:

template <typename T>
void print(const T& val)
{
    std::cout << val;
    print(); // we could have just print a new line here
}

And finally the recursive case:

template <typename T, typename... Args>
void print(const T& val, Args&&... args)
{
    std::cout << val << " ";
    print(args...);
}

Simple, isn’t it ? We just split the pack into a head element and a rest, for the rest of the pack.

Let’s put all that in a file and test it.

#include <iostream>
#include <random>

void print()
{
    std::cout << std::endl;
}

template <typename T>
void print(const T& val)
{
    std::cout << val << std::endl;
}

template <typename T, typename... Args>
void print(const T& val, Args&&... args)
{
    std::cout << val << " ";
    print(args...);
}

unsigned int_sqrt(unsigned n)
{
    unsigned r = n;
    while (n / r < r) {
        r = (r + n / r) / 2;
    }
    return r;
}

int main()
{
    std::string str("World");
    print("Hello,", str, "!");

    std::random_device              rd;
    std::mt19937                    gen(rd());
    std::uniform_int_distribution<> dis(27972, 755244);

    unsigned x = dis(gen);

    print("int_sqrt(", x, ") =", int_sqrt(x));
}

That’s a pretty simple example, but I hope I gave you the taste of digging it further.

That’s all folks

OK, this is it for today’s post (again, I’ve tried to stick to 30min, not counting the cat interruptions). Since the quarantine will probably continue for some weeks, I will probably have time to wrote more examples using parameter packs.

Destructor

In C++, any entity that goes out of scope get destroyed properly. For immediate values (integers, floats, pointers …) or POD (plain old data) this has basically no special consequences. But objects may provide a destructor.

Let start with a tiny demo to understand what we are talking about:

#include <iostream>

struct Demo
{
    // The constructor
    Demo()
    {
        std::cout << "calling ctor\n";
    }

    // The destructor
    ~Demo()
    {
        std::cout << "calling dtor\n";
    }
};


int main()
{
    Demo d;
}

When running we get:

shell> clang++ -Wall -Wextra -std=c++17 -O3 -o dtor dtor.cc
shell> ./dtor
calling ctor
calling dtor

You can track all the cases of destruction, but most of them are obvious. Those that are easily forgotten are: destruction of unamed objects and destruction of copy generated when calling function.

The power of the destructor

The purpose of RAII idiom is to take advantage of the pair constructor/destructor to handle resources properly. The pattern is pretty straightforward, you acquire the resource in the constructor and let the destructor takes care of properly releasing it.

One of the main advantage of this idiom is that, unless the program just dies, you are certain that the destructor will be called and thus you resources properly released. Even, if an exception is raised, the destructor will be called. This is exactly what you want for resource handling and completely transparent.

#include <iostream>

struct Demo
{
    Demo() = default;
    ~Demo()
    {
        std::cout << "dtor called\n";
    }
};

struct Exn
{};

int main()
{
    try {
        Demo demo;
        throw Exn {};
    } catch (const Exn& e) {}
}

The STL is using this idiom in a lot of places, you can see it in action in the <fstream> header. Another good example is std::scoped_lock, when creating it, it locks the real lock provided at construction and then unlock it when leaving.

Building a very simple smart pointer

Among the most useful things we can build with RAII are smart pointers. We will try to build a very simple and naive variation of std::unique_ptr. Let’s set up the scene with the easy part:

template <typename T>
class my_pointer
{
public:
    my_pointer() = default;
    // Construct by copy of the original value
    my_pointer(const T& val) : data_(new T(val)) {}
    ~my_pointer()
    {
        if (data_) {
            delete data_;
        }
    }

    T& operator*()
    {
        return *data_;
    }

    const T& operator*() const
    {
        return *data_;
    }

    T* operator->()
    {
        return data_;
    }

    const T* operator->() const
    {
        return data_;
    }

    void reset()
    {
        if (data_) {
            delete data_;
        }
        data_ = nullptr;
    }

private:
    T* data_ = nullptr;
};

I won’t go into the overload part (operator* and operator->), read a fine documentation.

The RAII idiom seems pretty obvious from the constructor (the one that take a value and perform a call to new) and the destructor.

But we have a problem: what happen if we do a copy construction of our smart pointer, what about move ? This code fails to one of the most important rule of C++. This rules can be summerized in: define all constructors and destructors, or defines none.

What is the problem here ? If you keep the default copy constructor, once copied, you have two object with the same pointer and after one of them is destroyed, the other one has a broken pointer. You have the same problem with the default move constructor. Since we are implementing a unique smarter pointer, we don’t want copy constructor (nor copy assignement). But we still need the move counterpart.

    my_pointer(const my_pointer&) = delete;
    my_pointer& operator=(const my_pointer&) = delete;

    my_pointer(my_pointer&& other) : data_(other.data_)
    {
        // other must not keep the pointer, otherwise we may face use after free
        other.data_ = nullptr;
    }

    my_pointer& operator=(my_pointer&& other)
    {
        if (data_) {
            // don't forget to delete existing data
            delete data_;
        }
        data_       = other.data_;
        other.data_ = nullptr;
        return *this;
    }

Handling copy and move operations is mandatory for RAII objects. You can see it as a way to define the life cycle of your resource: you define how to create it, how to release it and how to share it.

The std::vector class is showing another interesting application of RAII. The vector (and its content) are destroyed and the allocated memory release when the object get destroyed. But unlike our smart pointer, the copy will perform a deep copy of the underlying array. On the other hand, the move operations are transmitting ownership of the array to the new vector while resetting the source.

Good bye

This is it, it’s time to end this third quarantine post.

SFINAE: What’s that ?

The first keyword is Substitution, so it’s all about template. Substitution occurs when we instantiate a template and a variable of the template is replaced by it’s actual value. The point is that unlike most of what may happen at compile time, if substitution fails for a template (or a part of it), it does not generate an error at compile.

SFINAE is a trick that became a standard. We can use the SFINAE to select a specific implementation of a template without relying on explicit specialization.

Let’s start with an example. We want to implement a function that tells if a number is not negative, if we want it to work on all kind of numbers, without SFINAE we need to write a specialization for all types or write a blind template that accept any types. Let’s go directly in jungle:

#include <type_traits>

// unsigned are never negative
template <typename T>
std::enable_if_t<std::is_unsigned_v<T>, bool>  not_negative(const T& val)
{
    return true;
}

// if comparison against 0 works, it's ok
template <typename T>
auto not_negative(const T& val) -> decltype(val >= 0)
{
    return val >= 0;
}

This is not yet functional, but first let’s explore the code. The first version uses std::enable_if_t<cond,type> an SFINAE tools that is replaced by type if cond is true and not defined otherwise. So, if std::is_unsigned_v<T> is true (another SFINAE tool) this function is defined and always return true.

The second instance uses decltype, a static operator that evaluate the type of an expression, so here if val >= 0 is well typed, the function will have the same return type, so this function will be defined for any type T that can be used in comparison.

As I say, this is almost working. The problem is that if I try to instantiate that template with a type like unsigned int, both versions will be defined, we need something else. We can do something similar as the first one to exclude unsigned types, or we can use overloading priority to select the right function. Let’s see how to do that:

// Define a detail namespace to indicate that the following code are implementation details
namespace detail
{
// unsigned are never negative
template <typename T>
std::enable_if_t<std::is_unsigned_v<T>, bool>  not_negative_implem(const T& val, int)
{
    return true;
}

// if comparison against 0 works, it's ok
template <typename T>
auto not_negative_implem(const T& val, float) -> decltype(val >= 0)
{
    return val >= 0;
}
}

// Now the generic function
template <typename T>
bool not_negative(const T& val)
{
    return detail::not_negative_implem(val, 0);
}

Here we are using the fact that when selecting an overloaded verison, the compiler will select a version without type conversion first. So, if T is an unsigned type, since 0 is by default an int, the first overload will be selected, otherwise this version won’t be defined and it will try to instantiate the second.

The following code will demonstrate that code in action. I have added some print statement to see which version is used:

#include <iostream>
#include <type_traits>

// Define a detail namespace to indicate that the following code are implementation details
namespace detail
{
// unsigned are never negative
template <typename T>
std::enable_if_t<std::is_unsigned_v<T>, bool>  not_negative_implem(const T&, int)
{
    std::cout << "unsigned version\n";
    return true;
}

// if comparison against 0 works, it's ok
template <typename T>
auto not_negative_implem(const T& val, float) -> decltype(val >= 0)
{
    std::cout << "signed version\n";
    return val >= 0;
}
}

// Now the generic function
template <typename T>
bool not_negative(const T& val)
{
    return detail::not_negative_implem(val, 0);
}

int main()
{
    unsigned short un = 42;
    long sig = -12;
    if (not_negative(un)) {
        std::cout << "not_negative is true\n";
    }
    if (not_negative(sig)) {
        std::cout << "not_negative is true\n";
    }
}

Compile and run:

shell> clang++ -Wall -Wextra -std=c++17 -o sfinae01 sfinae01.cc
shell> ./sfinae01
unsigned version
not_negative is true
signed version

We can do lot more with this, I have already wrote a post on SFINAE: https://slashvar.github.io/2019/08/17/Detecting-Functions-existence-with-SFINAE.html

Defining type traits

The standard provide a lot of type traits, but we can define our own using SFINAE too. Here is a quick example, a type traits that evaluate to true if instances of a type provide a function member size(). And as a bonus, it can give you the return type of this function.

// Does T provide a size member ?

// Fallback if T::size() is not defined
template <typename T, typename = std::void_t<>>
struct has_size
{
    static constexpr bool value = false;
};

// Specialization when T::size() is defined
template <typename T>
struct has_size<T, std::void_t<decltype(std::declval<T>().size())>>
{
    static constexpr bool value = true;
    using type                  = decltype(std::declval<T>().size());
};

As I have reach the time limit for this post, I will let you explore that code by yourself !

That’s all for today

This is the end of this quarantine post, if you didn’t know this topic before, you probably have something new to explore.

For the first one, I’ll pick my favorite beginner topic: C++ is not (that) hard. This quick tuto will try to demonstrate that you can write C++ without spending too much time on complex topic such as memory management.

Tiny sort

For this tuto, we will implement a simplified version of the unix command sort. This command read lines from the standard input (or a file, but let’s start with the standard input), sort them and write them sorted on the standard output. The command has more options but we don’t want to write an option parser.

We can implement a quick version in python, just to see where we are going.

from sys import stdin
if __name__ == '__main__':
    lines = []
    for line in stdin:
        lines.append(line.strip('\n'))
    lines.sort()
    for line in lines:
        print(line)

The code is really simple, of course, the C++ version will be longer, but not that much.

Setting up the scene

First, we need to prepare our program and include the needed components of the standard library.

// Algorithms (for sort)
#include <algorithm>
// Stream input and output
#include <iostream>
// Vector containers
#include <vector>

// The program entry point
int main()
{

}

If you want to know more about these includes, I strongly encourage you to use http://cppreference.com and explore this fine documentation.

We don’t have code yet, but it could be a good idea to start compiling your program. Being an old fashioned dev, I prefer compiling from a terminal. Since we are working with a single file, we don’t need a build manager. I’m using clang++ as my compiler but g++ will work exactly the same here. Let’s assume the code is in a file called my_sort.cc and we want to produce a binary called my_sort:

> clang++ -Wall -Wextra -std=c++17 -O3 -o my_sort my_sort.cc

This command should produce a program called my_sort. We build with the most common warning flags (-Wall and -Wextra), we use optimizations at level 3 (not for the perf, but for the extra warnings it brings) and we assume C++17 standard (but C++11 or C++14 should work too).

Reading the standard input

C++ has several tools to do I/Os, but the easiest to use are the streams library. Since we are just reading lines, the best tool at hand is std::getline. As a first demonstration, we will read and reouput the line from the standard input:

int main()
{
    for (std::string line; std::getline(std::cin, line);) {
        std::cout << line << std::endl;
    }
}

std::cin is the standard input and std::cout the standard ouput. The loop is pretty similar to what we’ve done in python, while std::getline don’t return false (it’s not exactly what it returns, but that will be enough for today) we read a line and assign it to line.

Note the usage of the operator << to output what we have read.

We can try that piece of code:

shell> ls
my_sort.cc my_sort.py
shell> echo "line 1" > foo
shell> echo "line 2" >> foo
shell> clang++ -Wall -Wextra -std=c++17 -O3 -o my_sort my_sort.cc
shell> cat foo | ./my_sort
line 1
line 2

Storing the lines

Since we need to sort the lines, we need to sort store them. We need the simpliest form of container, a vector.

int main()
{
    // A vector of strings
    std::vector<std::string> lines;

    // Read and store the lines
    for (std::string line; std::getline(std::cin, line);) {
        // the line is copied in the vector
        lines.push_back(line);
    }
    // Print the lines
    for (const auto& line : lines) {
        std::cout << line << std::endl;
    }
}

The storing part is pretty straightforward, we push at the back the line we have just read.

For the output, we use a form of for each loop. The variable is declared as const auto& meaning that we don’t need to modify it (const) and we don’t want a copy but just a reference (the &) and since we are lazy we don’t want to write std::string again and use auto instead.

This code should have the same output as the previous example.

Sort ?

The STL (Standard Template Library) provides a lot of interesting tools and algorithms. We can find a sort function (std::sort, what a surprise).

But you can’t write std::sort(lines), it doesn’t work that way. Algorithms takes iterators, a begin and an end. In our case, we want to sort the whole vector, for that we will use the two functions that provide the begin and end of the vector. So all we have to do is to add the following line:

    std::sort(lines.begin(), lines.end());

std::sort can be used to sort only a part of a container or can take a comparison function, read the doc if you want to know more about it.

Putting everything together

Now we can see or full my_sort command:

// Algorithms (for sort)
#include <algorithm>
// Stream input and output
#include <iostream>
// Vector containers
#include <vector>

// The program entry point
int main()
{
    // A vector of strings
    std::vector<std::string> lines;

    // Read and store the lines
    for (std::string line; std::getline(std::cin, line);) {
        // the line is copied in the vector
        lines.push_back(line);
    }
    // Sort the lines
    std::sort(lines.begin(), lines.end());
    // Print the lines
    for (const auto& line : lines) {
        std::cout << line << std::endl;
    }
}

We can compile and try our code:

shell> seq 10 | sort -R > random-lines
shell> cat random-lines
6
9
8
3
5
1
4
10
7
2
shell> clang++ -Wall -Wextra -std=c++17 -O3 -o my_sort my_sort.cc
shell> cat random-lines | ./my_sort
1
10
2
3
4
5
6
7
8
9

Note that we are sorting string, hence 10 is before 2, just try with cat random-lines | sort and you will get the same output.

“I’ve learned that in C++ you must manage memory, are we safe here ?”

Short version: Yes !

In C++, objects that go out of scope are implicitly destroyed. For objects containing resources (like a vector or a string), if they are properly implemented (hopefully this is the case for those provided by the STL) they will release their resources when destroyed.

Can we be sure ? Yes, we can try to run our code with tools to check for memory leak. The simplest way is to use the address sanitizer provided by clang and gcc. If we have memory leak at the end, we will see some errors:

shell> clang++ -Wall -Wextra -std=c++17 -fsanitize=address -O3 -o my_sort my_sort.cc
shell> cat random-lines | ./my_sort
1
10
2
3
4
5
6
7
8
9

Going further ?

You can push this code a little bit further and take a file name as argument, and read from it rather than from the standard input. Or you can try to see how to build a numeric sort.

Goodbye

That’s all for today, that was an easy one, I will try to write something a bit more advanced tomorrow, maybe something with template or RAII.

Of course, there’s a lot of presentation about SFINAE and the STL provides some useful tools based on it. I don’t want to write another basic introduction to it, so I decided to peak a topic for which I didn’t found any example easily.

That’s lead us to the beginning of the title of this post: Detecting functions existence. We often have to provide replacement for library functions that are not available everywhere, depending of the OS or a library version. I’ll use as an example quick_exit(3) which is supposed to be part of the ISO standard but is not available on MacOS, we had the issue recently and while we’re not running our software on Mac, a lot of members of my teams are using Mac laptop as dev machine, so we need to be able to at least compile our code on it, but we don’t need a full-blown replacement and using _exit or _Exit will be enough in that case.

Of course, I wanted something that was not based on macros and I wanted it relying on the presence of the function. Hence the SFINAE approach.

But first, let see what we’re talking about.

Substitution Failure Is Not An Error

SFINAE stands for Substitution Failure Is Not An Error. Does it helps ?

In short, the compiler will not produce errors in some substitution cases and just ignore the faulty code. It can be surprising that such a behavior makes any sense in the first place, but it’s in fact a very powerful feature. If you think of it, sometimes you instantiate a template but not all operations provided by it make sense with the provided parameters. As long as you don’t use them, you’re fine. This silent failure is very convenient in a lot of cases. The basic usage of this is to forbid generic operations on type for which it doesn’t make sense. Let’s take a simple example:

template <typename T>
auto sum(T&& x, T&& y) -> decltype(x + y)
{
    return x + y;
}

In this example, the return type of the function is the type of x + y, if T does not support operator +, the expression x + y is ill formed, and the templated function won’t be defined for it. It’s as simple as that.

But we can also use it to provide specialized version based on similar property.

namespace details {
template <typename T>
auto print_sum_implem(const T& x, const T& y, int) -> decltype(x + y)
{
    auto res = x + y;
    std::cout << "Sum of " << x << " and " << y << " = " << res << std::endl;
    return res;
}

template <typename T>
int print_sum_implem(const T&, const T&, double)
{
    std::cout << "Sum is not possible !\n";
    return 0;
}

}

template <typename T>
auto print_sum(const T& x, const T& y)
{
    return details::print_sum_implem(x, y, 0);
}

It’s a bit out-of-the-box and not really meaningful, but it shows you what can be done. Note the usage of an extra parameter (int or double), it’s here to guide the overloading choice since both version are valid when T support +, we instruct the compiler to prefer the first version since int is a better match for 0 than double.

The header <type_traits> contains several useful tools to leverage SFINAE more easily like std::enable_if and various tests on types.

Detecting functions

OK, so what I want now is to be able write a wrapper for quick_exit(3) using _exit if it’s not available. And guess what, it appears to be pretty straightforward ! Just check if the function exists using decltype and you’re good.

We will be using the same int vs float tricks to prioritize the version using quick_exit, add the required attributes ([[noreturn]]) and lock detail implementation in its own namespace.

namespace details {
template <typename T>
[[noreturn]] auto quick_exit_impl(T status, int) -> decltype(quick_exit(status))
{
    quick_exit(status);
}

template <typename T>
[[noreturn]] auto quick_exit_impl(T status, double) -> void
{
    _exit(status);
}
}

[[noreturn]] static void my_quick_exit(int status) noexcept
{
    details::quick_exit_impl(status, 0);
}

The name of your wrapper have to be non ambiguous, you can easily end with infinite recursion otherwise.

Of course, having a #if __My_OS__ test looks simpler, but now you only rely on the existence of the function, not the possible versions you’re aware of.

This can be very useful, people using OpenSSL may have suffer from their API breaks between various versions, you can have a proper wrapper hiding it this way.

Going further

There’s a lot of possibilities when playing around with SFINAE and type traits in general. For example, we are using a wrapper template that injects if needed bound checking when passing unsigned sizes with proper types to function taking int as size (think of OpenSSL broken API).

As an example, let’s build a less function that compare two integer of different types properly. The promotion of integers type can go pretty wrong when comparing a signed integer with an unsigned one, just as a matter of example, try the following example:

int main()
{
    int x = -1;
    unsigned y = 1;
    if (x < y) {
        std::cout << "Good\n";
    } else {
        std::cout << "Bad\n";
    }
}

Guess what ? It displays Bad (and you got a warning at compile time). The reason ? when comparing two different types, the compiler is forced to inject conversions, in this case, the rules state it must convert the int (which has a lower rank than unsigned) into unsigned. Despite the fact that as of today, nothing force the compiler to use two’s complement, the conversion rules from signed to unsigned generate the same results, and -1 becomes the maximum value for unsigned.

So, what we want is a generic function that returns the comparison safely. The comparison of x < y depends on signedness of x and y, assuming that x is signed but y is not, the comparison should be:

    (x < 0) || static_cast<unsigned>(x) < y;

In the opposite case (y signed) we can build a similar test.

So, what do we need ?

• A version that return the comparison directly if the two parameter have the same signedness and the comparison is defined for their type.
• A version when the first argument is signed but not the second
• A version when the second is signed

As a side effect, non numeric types have the same signedness (provided that we test it correctly) and thus the first version will be defined as long as we can compare the two types.

Here is the implementation

template <typename T, typename U>
struct is_same_signedness
{
    constexpr static const bool value = std::is_signed<T>::value == std::is_signed<U>::value;
};

template <typename T, typename U>
auto my_less(const T& x, const U& y)
    -> std::enable_if_t<is_same_signedness<T, U>::value, decltype(x < y)>
{
    return x < y;
}

template <typename T, typename U>
auto my_less(const T& x, const U& y)
    -> std::enable_if_t<std::is_signed<T>::value && std::is_unsigned<U>::value, bool>
{
    using uT       = std::make_unsigned_t<T>;
    using target_t = typename std::conditional<sizeof(uT) < sizeof(U), U, uT>::type;
    return x < 0 || static_cast<target_t>(x) < static_cast<target_t>(y);
}

template <typename T, typename U>
auto my_less(const T& x, const U& y)
    -> std::enable_if_t<std::is_unsigned<T>::value && std::is_signed<U>::value, bool>
{
    using uU       = std::make_unsigned_t<U>;
    using target_t = typename std::conditional<sizeof(T) < sizeof(uU), uU, T>::type;
    return y > 0 && static_cast<target_t>(x) < static_cast<target_t>(y);
}

We first define a type traits to test for same signedness (we could avoid it, but the code looks better that way) and we use it to construct the version that work for types with same signedness and defined comparison.

Then we have the two version depending on signedness of parameters. We use SFINAE to select the correct version and use other construction provided in <type_traits> to properly promote both side to the bigger unsigned type.

The test for same signedness is mandatory since (unfortunately) x < y is not ill-formed when x and y are numeric types even if they have different signedness, thus we need to ensure that this version is not defined in this case.

We could have used if constexpr and merge in a single specialization the second and third one, but I find this presentation more explicit. In the first specialization, we could also avoid the decltype in the return type and use a static_assert providing a more explicit error message.

While you may find this definition a bit complex, if you need safe comparison between signed and unsigned types, this kind of construction provides a reusable code and helps avoid repeating the testing pattern. And since it supports all comparable types, you can use it in templates and all form of generic code safely. Bonus, once instantiated, the code is sufficiently simple to be elected for inlining and you can expect it to be as efficient as writing the test directly.

Conclusion

In this post, I’ve just scratched the surface of what can be done with SFINAE. I think this illustrate one of the most interesting aspect of C++ and modern C++: providing smart tools aimed at increasing abstraction with almost no impact at run-time, also called zero-cost abstraction.

The growing availability of constexpr constructions (evaluation at compile time of standard expression of the language) and the increasing accessibility of SFINAE open new horizons and the hope for a better language without boilerplate code, dangerous usage of preprocessor or the need of code generators.

I’ll focus on a tiny piece of code I wrote to verify a concept. After reading the chapter on singletons, I thought of a missing approach to the KDL (Keyboard, Display, Log) issue. This book exposes a classic issue: we have two singletons handling resources (K and D) and a singleton handling logs (Log). We want to avoid constructing the Log singleton when we don’t use it, but we want it to be available at any moment, and for it to be properly destroyed when we leave.

The book offers various solutions, such as the Phoenix Singleton (we rebuild the object when needed), or longevity management (an excellent idea for sure). However, what if we could partially construct the Log instance early on, only handling the cheap part, and keep the expensive job only when needed? We can perform an early construction by using a value instance rather than a pointer, which is safe as long as no other singleton of the same kind (value instance) refers to it.

Of course, this should be generic. What I want is a generic object that can postpone the creation of another object and provide a kind of proxy to it. Let’s call this object Defer_constructor.

Disclaimer: this is purely experimental. I didn’t explore all the possible implications and risks of such a construction. Don’t use my code in production.

Defer_constructor is a kind of smart pointer!

Deferring execution sounds like command/functor, but the important part is the proxy idea. Outside of the object, the fact that we construct the inner object on-demand is hidden (and somehow irrelevant).

We’re only building a POC, so I chose a simple model for my smart pointer, no reference counting or thread-safety. I’m sticking to a straightforward concept that only supports move semantics and provides object creation.

The starting point of my class looks like this:

template <typename DeferedType>
class Defer_constructor
{
public:
    using type = std::add_pointer_t<DeferedType>;

    Defer_constructor() = default;

    Defer_constructor(const Defer_constructor&) = delete;
    Defer_constructor& operator=(const Defer_constructor&) = delete;

    Defer_constructor(Defer_constructor&&) = default;
    Defer_constructor& operator=(Defer_constructor&&) = default;

    ~Defer_constructor()
    {
        if (instance_ != nullptr) {
            delete instance_;
        }
    }

    type operator*();

    type operator->();

private:
    type instance_ = nullptr;
};

We’re supporting default move semantics (constructible and assignable), we explicitly forbid copy, and we store an instance pointer. Even if we didn’t provide implementations yet, we have the expected overloading of * and ->.

Note the use of std::add_pointer_t<DeferedType>. We could have written DeferedType*, but we have a type trait handling this. It may solve some obscure corner cases.

Constructing the instance

We now need to provide a way of constructing the instance and be prepared to support any form of constructors. That’s when I realized how significant the changes that happened during the last decade are. In Alexandrescu’s book (back from 2001), there were no parameters pack, thus no variadic templates, no tuples, no lambdas. We have all this now.

We need:

• a way of accepting any parameters for the instance’s constructor,
• a way to store them and pass them later on.

Fortunately, we don’t need to support multiple ways of constructing the instance, since we accept these parameters at creation time. We, therefore, know their types statically.

Here is the updated skeleton to support all parameters for our instance. The choice we’re making here may not be optimal (we’ll see why later on), but it works:

template <typename DeferedType, typename... Args>
class Defer_constructor
{
public:
    Defer_constructor(Args&&... args);
};

We want to be able to accept an unknown number of arguments. For this, we can use parameters pack (and && for perfect forwarding). Nothing fancy. Yet, how do we store that? We can’t have an attribute holding Args... args, do we?

Another recent C++ addition can save us: tuples! We can store the parameters in a tuple, and later find a way to pass it to the constructor.

You may be thinking, “why not use std::bind ?”. That was my first idea, but you can’t bind a constructor. While searching for a solution, I ended up finding some template related to tuples and thought it could be helpful. However, we could definitely have stored a bind to a function that creates an instance for us. You can give it a try!

Back to the tuple, here is the first version that stores data:

template <typename DeferedType, typename... Args>
class Defer_constructor
{
public:
    Defer_constructor(Args&&... args) : _args(std::forward<Args>(args)...) {}
private:
    std::tuple<Args...> _args;
};

Looking good? Yes, we’re probably missing something. What happens if one of the parameters is a reference? Even worse, what happens if we get a reference to an object with a shorter lifetime? Bingo, a dangling reference!

Here, like with any other form of closure, we need to store copies of parameters. That’s a choice; we could also accept dangling references as a risk. However, the necessary code change to store copies is rather small, so let’s go for it.

template <typename DeferedType, typename... Args>
class Defer_constructor
{
public:
    Defer_constructor(Args&&... args) : _args(std::forward<Args>(args)...) {}
private:
    std::tuple<typename std::decay<Args>::type...> _args;
};

When we finally construct the instance

The previous section title was misleading: we only store parameters, but we didn’t provide a way to construct the instance.

How can we do this? We need a way to go back to an expression of the form.

    new DeferedType(std::forward<Args>(a)...)

Where a is a parameters pack.

Remember when I said I’ve ended up using a tuple thanks to some templates I found useful? Here we are: we have something called std::apply that’s made for this. It takes a callable object and tuple, and calls the object with elements of the tuple as parameters.

I’ve decided to wrap the new in a lambda, but we can probably pass the new operator of the class directly.

Another detail: we want to create the instance only it’s used. It’s used only through operator* and operator->, and the way they work is so similar that it makes sense to abstract the code in a private member (let’s call it acces_).

template <typename DeferedType, typename... Args>
class Defer_constructor
{
public:

    type operator*()
    {
        return acces_();
    }

    type operator->()
    {
        return acces_();
    }

private:

    type acces_()
    {
        if (instance_ == nullptr) {
            instance_ = std::apply(
                [](Args... a) { return new DeferedType(std::forward<Args>(a)...); }, _args);
        }
        return instance_;
    }
};

This is a classic singleton pattern with lazy instantiation: if the instance doesn’t yet exist, we create it. Otherwise, we only return the pointer.

Putting everything together and testing

Here is a full example with the complete Defer_constructor class, two toy classes for the demo, and a main.

#include <iostream>
#include <tuple>
#include <type_traits>

template <typename DeferedType, typename... Args>
class Defer_constructor
{
public:
    using type = std::add_pointer_t<DeferedType>;

    Defer_constructor() = default;

    Defer_constructor(const Defer_constructor&) = delete;
    Defer_constructor& operator=(const Defer_constructor&) = delete;

    Defer_constructor(Defer_constructor&&) = default;
    Defer_constructor& operator=(Defer_constructor&&) = default;

    ~Defer_constructor()
    {
        if (instance_ != nullptr) {
            delete instance_;
        }
    }

    Defer_constructor(Args&&... args) : _args(std::forward<Args>(args)...) {}

    type operator*()
    {
        return acces_();
    }

    type operator->()
    {
        return acces_();
    }

private:
    type                                           instance_ = nullptr;
    std::tuple<typename std::decay<Args>::type...> _args;

    type acces_()
    {
        if (instance_ == nullptr) {
            instance_ = std::apply(
                [](Args... a) { return new DeferedType(std::forward<Args>(a)...); }, _args);
        }
        return instance_;
    }
};

struct Foo
{
    Foo(int x, int y) : x_(x), y_(y)
    {
        std::cout << "Foo(" << x_ << ", " << y_ << ")\n";
    }

    int x_, y_;
};

struct Bar
{
    Bar(const std::string& str)
    {
        std::cout << str << std::endl;
    }
    void f()
    {
        std::cout << "f\n";
    }
};

int main()
{
    {
        std::cout << "Before creation of f2\n";
        Defer_constructor<Foo, int, int> f2(2, 2);
        std::cout << "After creation of f2\n";
        int& x2 = f2->x_;
        std::cout << "After use of f2 internal instance\n";
        std::cout << x2 << std::endl;
    }
    std::cout << "Now with the risk of dangling ref\n";
    Defer_constructor<Bar, std::string&>* later;
    {
        std::string str("Hello bar");
        later = new Defer_constructor<Bar, std::string&>(str);
    }
    (*later)->f();
    delete later;
    return 0;
}

Let’s try it now! I’m confident, so I’ll use clang with -fsanitize=address and -Weverything!

> clang++ -fsanitize=address -Weverything -Wno-c++98-compat -std=c++17 -O3 -o defer defer.cc
> ./defer
Before creation of f2
After creation of f2
Foo(2, 2)
After use of f2 internal instance
2
Now with the risk of dangling ref
Hello bar
f
>

Note that we need -Wno-c++98-compat since -Weverything really contains everything.

Do you remember when I said that the way we get the parameters types as template parameters was not perfect? Here we’re forced to write Defer_constructor<Foo, int, int> because Foo can’t be inferred from the call. Therefore, we must provide all parameters.

I kept it for future improvement.

Conclusion

First, it wasn’t that hard. Once we have the key ideas (tuple and std::apply), everything else follows smoothly.

Of course, there’s room for improvement. I am not at all confident about this code. I didn’t checked the generated assembly code, but I guess we can expect much inlining.

Bonus

I have one more little C++ stuff. It’s completely different, but since I am rather slow at pushing new posts, and this pattern is small, I wanted to share.

You may have noted the arrival of the [[nodiscard]] attribute in C++17. This is an advantageous one (in fact, most compilers offered a similar one before) when you have functions returning values that shouldn’t be discarded (e.g., a boolean that indicates an error).

Neat, but, as usual, we sometimes need to skip those return values for good. The problem isn’t to find a way of discarding it, but to do it in a way that’s explicit enough so that you can check it when reading the code, or even grep it.

Here is my solution:

template <typename T>
constexpr void ignore_value(T&&)
{}

I did not create it. For instance, in OCaml, the standard library provides a similar ignore function. I found it quite handy in this particular context, and since it’s explicit and easy to use, you no longer have to decipher void casts or empty if statement during code reviews.

Oh, and it also works when you need to ignore variables or parameters.

Another way to do this is to assign the result to std::ignore, but I find it less explicit.

But, before explaining this form of optimization, let’s see what is a tail recursive function.

There and Back Again

Let’s use a toy useless function as example. Say, you want to compute addition of integers, but you’re language only know how to compute +1 and -1, and of course, we want to do it recursively. Here is a quick implementation in python:

def add(x, y):
    if y == 0:
        return x
    return 1 + add(x, y - 1)

Forget about negative numbers, or cases where x == 0, we can solve them separetly.

If we run my function with 3 and 2, here are the execution steps:

add(3, 2) -> 1 + add(3, 1)
    add(3, 1) -> 1 + add(3, 0)
        add(3, 0) -> 3
              -> 1 + 3
          -> 1 + 4
-> 5

You can see that once you get the result of a recursive call, you can compute the +1 and then return your current result. We’re going there until we reach the stop case, and then back to compute the result.

Now, let’s use magical math tricks, and write a similar function:

def add(x, y):
    if y == 0:
        return x
    return add(x + 1, y - 1)

It looks pretty similar, it has the same complexity (linear on y), is it different ?

add(3, 2) -> add(4, 1)
    add(4, 1) -> add(5, 0)
        add(5, 0) -> 5
              -> 5
          -> 5
-> 5

Yes ! Once we reach y == 0, we have the final result, the rest of the steps are just a cascade of returns without any computations. This version is a tail recursive function !

A tail recursive function, is a function that returns a value without recursive call or returns the result of a recursive call directly, and nothing happen after the recursive calls.

Optimizing tail recursive functions

The optimization is pretty obvious, once we reach a direct return, we want to skip every frames of recursion and directly return from the original call.

How do we do that ?

Of course, it really depends on the way you run your language, but let’s assume that we’re in rather classic context, with a stack used for saving caller context and return address. Our context is of course composed of local variables (including parameters), the address of the beginning of the frame for the current function (the top of stack when arrived in the function, the frame pointer) and our own return address. Saving context on the stack means that we push the frame pointer and the return address and we then we can push parameters and jump to the callee. When we return from a function, we restore the frame pointer and jump back on the return address. The details are not that important, it may even be partially done by processors instruction, we don’t care.

So how do we perform the tail recursion optimization ? After the initial call, we just don’t save the context ! That way, when we return, we return as if we were in the original call. It works because we are sure that nothing happens after the return and thus we don’t need our context anymore. If you want more details, open a compilation book, this is one of the classical optimization and it’s pretty easy to implement.

It has two main impacts: we do only half of the jump (only there and no back) and we use a constant space on the stack.

OK, this is highly theoretical, isn’t it ? Can we see this optimization in different way without relying on the compilation strategy ? Let’s try.

First, let’s take a more accurate example, binary search, in C this time:

int binary_search(int *begin, int *end, int x) {
    if (begin >= end) {
        return 0; // x is not in [begin, end[
    }
    int *mid = begin + (end - begin) / 2;
    if (x == *mid) {
        return 1; // we found it !
    }
    if (x < *mid) {
        return binary_search(begin, mid, x); // search in the first half
    } else {
        return binary_search(mid + 1, end, x); // second half
    }
}

OK, the idea is to rather than call the recursive function, replace begin or end, and then jump at the beginning of the function. Let’s use goto for that (yes, I’ve heard your screams):

int binary_search(int *begin, int *end, int x) {
  _start:
    if (begin >= end) {
        return 0; // x is not in [begin, end[
    }
    int *mid = begin + (end - begin) / 2;
    if (x == *mid) {
        return 1; // we found it !
    }
    if (x < *mid) {
        end = mid;
        goto _start;
    } else {
        begin = mid + 1;
        goto _start;
    }
}

Let’s refactor the first if a bit:

int binary_search(int *begin, int *end, int x) {
  _start:
    if (begin < end) {
        int *mid = begin + (end - begin) / 2;
        if (x == *mid) {
            return 1; // we found it !
        }
        if (x < *mid) {
            end = mid;
            goto _start;
        } else {
            begin = mid + 1;
            goto _start;
        }
    }
    return 0; // x is not in [begin, end[
}

Hey, it’s looks like a while loop ! Yes, this is exactly what this optimization is about, transforming tail recursive functions into a loop !

int binary_search(int *begin, int *end, int x) {
    while (begin < end) {
        int *mid = begin + (end - begin) / 2;
        if (x == *mid) {
            return 1; // we found it !
        }
        if (x < *mid) {
            end = mid;
        } else {
            begin = mid + 1;
        }
    }
    return 0;
}

Cool, we no longer need to bother, do we ?

Remember the first function ? You can’t directly optimize it, you need to first transform it into at taill recursive one, and that’s not always obvious. The good news is that, it’s theoretically always possible, the bad news is that it’s not always that simple. For simple, single call functions, it’s a matter of adding some parameters in order to carry more information. But even in thoses cases, you need to be sure that you can reorder the operations. Let’s see a classic trap:

def list_of_int(n):
    if n == 0:
        return []
    r = list_of_int(n-1)
    r.append(n)
    return r

We can pass the result list as a parameter and transform that into a tail rec version:

def list_of_int2(n, r):
    if n == 0:
        return r
    r.append(n)
    return list_of_int2(n-1, r)

Now, we run both:

print(list_of_int(5))
print(list_of_int2(5, []))

We get:

[1, 2, 3, 4, 5]
[5, 4, 3, 2, 1]

I let you correct it …

More calls, more problems

First, start with an easy one, Fibonacci. For that one, we need to add parameters and inverse the order of computation:

def fibo(n):
    if n < 2:
        return 1
    return fibo(n-1) + fibo(n-2)

# Becomes

def _fib(n, i, f_i, f_i1):
    if i == n:
        return f_i
    return _fib(n, i+1, f_i + f_i1, f_i)

def fibo(n):
    if n < 1: return 1
    return _fib(n, 1, 1, 1)

Note that while the function computes the same values, it is not a transformation of the first one but a different algorithm, a kind of recursive version of the loop based one.

Now, say I have a binary tree and I want to compute its size:

class Tree:
    def __init(self, key, left=None, right=None):
        self.key = key
        self.left = left
        self.right = right

def size(t):
    if t == None:
        return 0
    return 1 + size(t.left) + size(t.right)

It becomes a bit more tricky no ? Unlike Fibonacci, we can’t avoid the call on each node of the tree, we need to find a way to do them. For that, we can use a stack !

I’ll give you directly the loop version, it makes more sense:

def size(t):
    if t == None:
        return 0
    sz = 0
    stack = [t]
    while len(stack) > 0:
        n = stack.pop()
        sz += 1
        if n.right:
            stack.append(n.right)
        if n.left:
            stack.append(n.left)
    return sz

Note the order of the push, to be sure that we traverse the tree in the same order.

OK, but now, what if I want to print my tree in order (the root in the middle):

def in_order(t):
    if t == None:
        return
    in_order(t.left)
    print(t.key)
    in_order(t.right)

The trick of stack is not enough, we need to simulate the there and back again, so we really need to see each node at least twice !

def in_order(t):
    if t == None:
        return
    stack = [(t, True)]
    while len(stack) > 0:
        n, cont = stack.pop()
        if cont:
            stack.append((n, False))
            stack.append((n.left, True)) if n.left
        else:
            print(t.key)
            stack.append((n.right, True)) if n.right

And if you need to do something in-order and post-order (so between the children and after the children), you will need to push each node three times in the stack. Of course, with general trees, or graph, this becomes even more complex.

Does it really matters ?

So, yes, it matters. Of course, with binary trees, maximum size of the stack is linear in the depth of the tree which is most of the time not that big even for big trees. But what about graph ?

Here is a classic algorithm that finds the cut-points of a connected undirected graph:

def _cut_points(g, v, parent, c, pre, cuts):
    c[0] += 1
    pre[v] = c[0]
    high = c[0]
    children = 0
    for succ in g[v]:
        if pre[succ] == None:
            children += 1
            r = _cut_points(g, succ, v, c, pre, cuts)
            if parent != None and r >= pre[v]:
                cuts.add(v)
            high = min(high, r)
        elif succ != parent:
            high = min(high, pre[succ])
    if parent == None and children > 1:
        cuts.add(v)
    return high

def cut_point(g):
    cuts = set()
    c = [0]
    pre = [None] * len(g)
    _cut_points(g, 0, None, c, pre, cuts)
    return cuts

OK, it’s a DFS (depth first traversal) of an undirected graph, with pre-order counting (the array pre using c to store the counter and simulate a reference). It works with a similar idea as Tarjan’s algorithm for finding strongly connected components, but translated to undirected graphs.

The graph is represented as adjacency list: it’s an array of lists, vertices are numbered from 0 to the order of the graph and g[v] is the list of successors of v.

You can extend it to compute cut-edges and build 2-connected components. Open a good algorithms text book if you want to know more about it.

What we see here is that we have multiple recursive calls (in a loop) and we perform operation in pre-order, after each call and in post-order. So we need to meet each vertex a first time, then do something after each of it’s successors and then a last time. It’s easy to see that removing recursion won’t be easy …

Why this example ? Some years ago, for some experiments with huge graphs, I needed the cut-points and I implemented the very same algorithm (in C++). On huge graphs, highly connected, the recursion depth was pretty high and I ended up with a lot of stackoverflow. The only way to get it to work, was to derecursify it. It’s doable, it’s finally not that ugly (a big thanks to C++ iterators) and it saved my experiments !

Let’s see our python version:

def cut_points_iter(g, v = 0):
    cuts = set()
    high = [None] * len(g)
    parent_it = [0] * len(g)
    pre = [None] * len(g)
    parents = [None] * len(g)
    root_children = 0
    c = 1
    pre[v] = c
    parents[v] = v
    high[v] = c
    stack = [ (v, -1, 0) ]
    while len(stack) > 0:
        v, ret, it = stack.pop()
        if ret != -1:
            if parents[v] == v:
                root_children += 1
            else:
                if ret >= pre[v]:
                    cuts.add(v)
                high[v] = min(high[v], ret)
            it += 1
        while it < len(g[v]) and pre[g[v][it]] != None:
            if g[v][it] != parents[v]:
                high[v] = min(high[v], pre[g[v][it]])
            it += 1
        if it < len(g[v]):
            if it + 1 < len(g[v]):
                stack.append( (v, -1, it + 1) )
            succ = g[v][it]
            stack.append( (succ, -1, 0) )
            c += 1
            pre[succ] = c
            high[succ] = pre[succ]
            parents[succ] = v
            parent_it[succ] = it
        else:
            if parents[v] == v:
                if root_children > 1:
                    cuts.add(v)
                return cuts
            stack.append( (parents[v], high[v], parent_it[v]) )
    return cuts

Looks a little bit more complex, isn’t it ?

How it works ? In the original version, for each vertex, we have several steps:

• we need to iterate on each successor:
  • if the successor has not been seen yet, we continue the traversal on it
  • when returning from a recursive call, we have some checks to do with the result
  • if the the successor is marked (already seen) we have another check
• we have a special last step for the root
• we have a result to return

So, the idea is to schedule as much context as possible, first vertices are clearly identified by an id, we can thus store some contextual information in arrays (high, parent_it, parents), we can then build the information we want to schedule for the next iteration: the idea is to schedule the parent and the position in of the target vertex in the its parent successors list, thus v is the parent and g[v][it] represents the current vertex. And last element, since we need to handle the return, we also had the return value to the context (ret).

With that in mind, you should be able to reconnect the different steps of the recursive version. Note that the first vertex (the root) has some special treatement that are more explicit in the iterative version (which can be misleading). It’s not an easy task if you don’t understand the original algorithm, so spend some time on it first.

Conclusion

To connect with my introduction, the first thing to remember is, yes, compilers are able to optimize tail recursive functions, yes it makes some algorithms more tractable (a bit faster but mostly it avoids stackoverflows) but, no, it’s not magical, you need to do the hardest part, make your Function tail recursive in the first place !

Of course, talking about pointers implies talking about C or C++, they are the two languages where you need them most, and while you can avoid them, pointers are everywhere in programming, it is just that sometimes they’re hidden by the language.

This post requires at least some basic knowledge of C, mostly its syntax and the most obvious part of its semantics. If you’re not a C programmer (but you’re familiar with languages that use C syntax like Java) don’t be afraid, you will probably be able to understand most of the text and, I hope, you will learn something useful.

A bit of theory

For the sake of clarity, the rest of the text will assume a simple memory model which more or less maps to what you could find on modern PCs running Linux. That is, a model where memory addresses are just unsigned integers indexing bytes.

The semantics of the C programming language, in order to support (almost) any kind of architecture, is more complex. This model explains some particular undefined behaviors.

In short, what is defined is that you got addresses and you don’t know their nature. The language only guarantees the expected behavior of arrays and of pointers used as arrays. The whole definition of pointers is a bit obscure and it defines mostly when pointers are supposed to be equivalent to one another and/or defined.

That is to say, you can live with it as long as you don’t try to rely too much on the numerical nature of pointers outside of arrays. But keep in mind that anything that is not explicitly defined (or defined as implementation dependent) may be compiled differently than what you expect.

So far for the theory.

there is no arrow

The most common illustration of pointers involves boxes and arrows. After several years of teaching C, it appears to me that this is the worst way of presenting pointers.

A pointer is a value (often numerical) like any other. In order to manipulate it, you need to store it (in a variable, a field of a structure, an array cell…) and you can copy it to another storage. It can be valid or uninitialized, it can become invalid…

int x = 42;	// we need an address to init our pointer
int *p;		// p is a variable that can contain a pointer to an int
p = NULL;	// p contains the null address, an existing but unusable pointer
p = &x;		// p now contains the address of x
int *q = p;	// q is a variable containing the same address as p
int y = 0;	// another variable in order to have an address
p = &y;		// p contains the address of y, q still contains the one of x
printf("%d %d\n", *p, *q);

When declaring a pointer as in int *p, you define a storage (a variable) where you can put an address ; but until you initialize it with a proper address, it is unusable, just like any other variable.

Just like an address in real life, if you write it in your contact book, it doesn’t mean that it will be updated when the people living here move or if the house is destroyed. And if you have a line for the address of a contact but don’t put anything inside (or put something that is not an address) you won’t be able to send any letter to that address as it is not valid !

Once you have this in mind, you will be able to understand most errors related to pointers. It doesn’t mean that you won’t make errors, or that you will find them easily, but at least you know what you’re playing with.

Let’s now move to the basics.

Basic usage of pointers

The following piece of code illustrates classical usage of pointers. Read it and read the comments !

#include <stdio.h>
#include <stdlib.h>

/*
 * reset(a) puts 0 at the address a
 */
void reset(int *a)
{
  *a = 0;
}

/*
 * swap(a, b) swaps the integers stored at address a and b
 */
void swap(int *a, int *b)
{
  int c = *a; // copy in C the value stored at address a
  *a = *b;    // copy at the address in a the value at b
  *b = c;     // copy the value from c at the address in b
}

/*
 * divide(a, b, m) returns a/b (as int) an stores at m the rest
 * if b is null, returns 0 and don't touch what m points to
 */
int divide(int a, int b, int *m)
{
  if (b == 0) {
    return 0;
  }
  *m = a % b;
  return a / b;
}

int main()
{
  int x = 27;
  printf("x = %d\n", x);
  reset(&x); // send to reset the address of x
  printf("x = %d\n", x);

  int a = 2, b = 42;
  printf("a = %d\nb = %d\n", a, b);
  swap(&a, &b);
  printf("a = %d\nb = %d\n", a, b);

  int m = -1;
  printf("a/b = %d\n", divide(a, b, &m));
  printf("m = %d\n", m);

  return 0;
}

You can compile that code and run it:

> make basic
cc basic -o basic.c
> ./basic
x = 27
x = 0
a = 2
b = 42
a = 42
b = 2
a/b = 21
m = 0

Just to resume what we have seen: reset(a) is a function that uses a pointer to store a value outside of its scope; swap(a, b) exchanges the content of 2 addresses and divide(a, b, m) computes integer division and stores the rest at an address provided. These three functions illustrate a common (basic) use case of pointers: being able to modify variables (or any storage) outside of the current function.

Even if it is not the official vocabulary, you can see this as a reference call semantics, you pass a reference to a local variable in order to modify it.

The traditional call semantics of almost every language is a call by value: a function’s parameters’ values are copied into the parameter storage. If you want to modify variables local to the caller, you must pass the address of those variables. The callee always assumes that you pass valid addresses (it can’t verify them anyway…).

Note: in many higher level programming languages (dynamic or not like Python, Java, OCaml…), complex values are always manipulated through pointers This means that when you pass them to a function, you pass them by reference. This is often called pass by object reference. In my experience for beginners never exposed to pointers before, the induced behavior is often disturbing: you are able to do some operations that modify the parameters in the caller scope, but some modifications are still local. Explained through pointers, this is far more simple: you have this address on an object, you can modify what the address point at but any operations modifying the address itself acts only at the local scope.

To illustrate this last point (still in C), let’s write a function that swaps two pointers. Not the content pointed to but really the addresses:

void swap_pointer(int **a, int **b)
{
  int *c = *a;
  *a = *b;
  *b = c;
}

We just add a level of stars, this way we can change the address since we have a pointer to a location containing an address. The only differences are on type, the rest of the swap is similar.

Common mistakes

there is an infinte number of ways to misuse pointers. Let’s see some classical errors.

Returning pointers

A pointer is a value and like any other value. You can return a pointer in a function.

// Global variable for the sake of the example
int my_global = 42;


/*
 * a useless function
 */
int* address_of_my_global()
{
  return &my_global;
}

when an address is returned by a function, you can expect that callers of this function will use it. This means that: it must be valid (eventually NULL). To be valid and dereferencable, it must point to a storage that has a sufficiently long life time, like the example above (my_global will stay as long as the program runs). Returning the address of a local variable (or of a parameter) will inevitably leads to bugs, in fact this an obvious case of undefined behavior. As usual in C, it will seem to work in certain cases: local variables are stored on the stack which is a kind of draft for functions, right after the call, the content of the local variable may probably still be available, but as soon as another part of the program uses the stack it will be overriden.

/*
 * writing this code in real programs deserves being ashamed for life
 */
int* dont_do_that()
{
  int x = 42;
  return &x;
}

In obvious cases like this one, the compiler will be able to warn you:

shell> cc -Wall -Wextra -std=c11 -c dont_do_that.c
dont_do_that.c: In function ‘dont_do_that’:
dont_do_that.c:7:10: warning: function returns address of local variable [-Wreturn-local-addr]
   return &x;
          ^~

Note: I have used the the flags -Wall -Wextra. They activate the standard warnings (depending on your compiler, you can activate more warnings, clang for example provides a flag -Weverything that activates all possible warnings). You should always do that. Warnings are always the sign of something wrong. Sometimes you have a good reason, but it is more likely that the code will break at a later time.

Invalid and null pointers

Pointers (strictly speaking, variables of type pointer) can be in three states:

• initialized and valid: the address stored in the variable points to a living object in memory
• null: the pointer contained the so called null pointer, usually the address 0, represented by the macro NULL, in this case the pointer is valid but you can’t dereference it (access the value it is pointing to).
• invalid: the pointer has not been initialized, it contains garbage or the object at the referenced address no longer exits.

Dereferencing an invalid or null pointer is a case of undefined behavior and may lead to an error at execution (always for the null pointer, but for an invalid address you may have accidentaly gotten the address of another existing object).

Using an invalid pointer in an other kind of operation (like pointer arithmetic or even passing it to a function) is a case of undefined behavior. Note that you can use a null pointer in any operation not involving dereferencing. In the same vein, the address right after the one of an object (or the last object of an array) can be used in non-dereferencing operations.

This is the perfect time to talk about arrays and pointers arithmetic.

Arrays and pointers arithmetic

In most programming languages, an array is a contiguous area containing a collection of objects of the same type. They are of a fixed size (at some point at least, but you may be able to update their size).

In C, the implementation of arrays is related to pointers, but to the contrary of what a lot of people think, arrays and pointers are not exactly the same. But I will show you that later.

If my addresses are numerical, accessing an element of an array is as simple as taking the address of the first element and adding the amount of bytes corresponding to the number of elements to skip. For example, if I have 4 bytes integers and I want to access the third element, I will shift the address of the first by 4*2=8 bytes to skip the first two). Knowing the size of the elements is annoying, the compiler knows their type and thus their size. This is where pointer arithmetic shows up !

Adding an integer n to a pointer moves the address by n objects, provided that this pointer points to an array of at least n objects (the language guarantees the existence of the address of the last object plus one). So, you can navigate in arrays using additions!

/*
 * sums up the content of an array using the classical [] notation
 */
int index_sum(int array[], unsigned size)
{
  int res = 0;
  for (unsigned i = 0; i < size; ++i) {
    res += array[i];
  }
  return res;
}

/*
 * sums up the content using only pointers
 */
int pointer_sum(int array[], unsigned size)
{
  int res = 0;
  for (int *it = array; it != array + size; ++it) {
    res += *it;
  }
  return res;
}

These two functions are completely equivalent, and your compiler will probably generate a similar machine code for both.

In fact, the expression array[i] is completely equivalent to *(array + i) or, for pedantic C programmers, *(&array[0] + i).

Fun fact: we all know that addition is commutative, that is a + b is equivalent to b + a, in most algebra. This is true for pointers as well. It turns out that *(array + i) is equivalent to *(i + array) which means that you can write (but that’s naughty) i[array] !

A lot of code is using pointers directly rather than arrays, for a lot of reasons and this leads also to the concept of iterators in C++. If I rewrote my sum function this way:

int iterator_sum(int *begin, int *end)
{
  int res = 0;
  for (; begin != end; ++begin) {
    res += *begin;
  }
  return res;
}

It may look familliar to C++ programmers !

Using pointers arithmetic is useful in a lot of cases. This is a classical recursive implementation of a binary search (a lower bound in fact) using only pointers:

/*
 * find(begin, end, x) finds x in the sorted range between begin and end
 * returns the address of the first element not smaller than x if it is not
 * present
 */
int *find(int *begin, int *end, int x)
{
  if (end - begin < 1)
    return begin;
  int *mid = begin + (end - begin) / 2;
  if (x == *mid)
    return mid;
  if (x < *mid)
    return find(begin, mid, x);
  return find(mid + 1, end, x);
}

/*
 * iterative version
 */
int *find_iter(int *begin, int *end, int x)
{
  while (begin < end) {
    int *mid = begin + (end - begin) / 2;
    if (x == *mid)
      return mid;
    if (x < *mid)
      end = mid;
    else
      begin = mid + 1;
  }
  return begin;
}

In the previous functions, we have seen several interesting constructions:

• end - begin: pointers substraction yields the distance (in number of objects) between them
• find(begin, mid, x): a way to call with a smaller array
• find(mid + 1, end, x): a way to call a function in the middle of an array
• begin + (end - begin) / 2: computes the mid point. Note that we use half of the distance rather than the classical arithmetic mean ((begin + end) / 2) to avoid possible overflows (which, when manipulating pointers, will occur).

In all of the previous examples, I have used pointers to designate a range of objects, using the implicit convention that begin is the first element and end the first element outside of the range (half-open/exclusive range). This is a classical choice in programming. Not doing things that way, you will have to play a bit more at the risk of doing out-of-bounds access or forgetting elements.

Always use half-open ranges, with left bound included and right bound excluded.

What’s the difference between arrays and pointers ?

In most cases, there is almost no difference between arrays and pointers, in the sense that a pointer to a memory area containing several objects of the same type can be used as an array.

But, arrays (or static arrays) in C have a different nature. If you declare a variable that way (at local or global scope, it doesn’t matter):

int array[8];

array is not a pointer, in fact what you have just created is a block of 8 integers. But in most cases, if you use the variable array it will be replaced by the address of the first element, that is &array[0]. Thus, you can pass it to a function expecting a pointer to an int and you can assign a pointer with it, but, and this is important, it is not a left-value so it can’t be reassigned.

Array variables are not replaced by the address of the first element in cases where they are used for their types. Like when passing them to the operator sizeof (which will then return the size of the array itself in bytes rather than that of its elements), or when taking their address. Here are some examples illustrating the difference:

#include <stdio.h>
#include <stdlib.h>

int main()
{
  // an int
  int a = 0;
  // a pointer in order to have an address
  int *p = &a;
  // a traditional array
  int array[4] = {1,2,3,4};

  // Let's print some sizes
  printf("sizeof (p) = %zu\n", sizeof (p));
  printf("sizeof (array) = %zu\n", sizeof (array));

  return 0;
}

Compile and run:

shell> cc -Wall -Wextra -std=c11 -o array array.c
shell> ./array 
sizeof (p) = 8
sizeof (array) = 16

OK, you can see that the size of array is as expected 16 (4 * 4) and p being a pointer it is 8 (when executed on a 64-bit machine).

C99 introduces the notion of VLA (Variable Length Arrays). They are not strictly speaking dynamic arrays, but arrays whose size will be known at run-time. But once declared, they behave exactly as other arrays.

Dynamic ?

Arrays is a good topic to introduce dynamic memory allocation. Since the beginning, I have only used addresses of variables (or context where you didn’t know where the pointer came from). We have also seen arrays, but only static ones.

Sometimes, we need entities that have a longer lifespan than that of a function scope, a size that is not compatible with the size of the stack (where our local variables go) or simply a size that will only be known after some computations. For that, we are able to ask for memory using the function malloc(3) from the standard library (the 3 in the parenthesis refers to the section in the Unix man pages, not to a parameter. i.e. documentation is available via man 3 malloc).

This function takes a number of bytes and returns a pointer to an area of this size that you can use as you want. Where it is exactly depends on your system and your standard library. We often say that it is on the heap by opposition to the stack (what is the heap exactly? Where malloc allocates memory of course…)

malloc(3) doesn’t know what usage you will make of this pointer, which is why it returns the generic type of pointers, namely void*. Which can be seen as pointer to nothing or to anything… You can safely assign a generic pointer to any pointer variables and you can assign any pointer to a variable of type void*. But, you can’t dereference a generic pointer, nor can you do arithmetic with it.

malloc(3) guarantees that the memory area pointed to by its return value will be exclusively yours until you free it with free(3), you reallocate it with realloc(3) or the end of the program.

The most common usage of dynamically allocated memory is arrays, strings (which are in fact arrays of characters) and structures. You can allocate memory for a single basic object like an integer, but it is probably a waste of space…

Let’s illustrate it with an example:

#include <stdio.h>
#include <stdlib.h>

int sum(int *begin, int *end)
{
  int res = 0;
  for (; begin != end; ++begin) {
    res += *begin;
  }
  return res;
}

int main()
{
  // a dynamic array of 8 integers
  int *a = malloc(8 * sizeof (int));
  // malloc(3) can fail
  if (a == NULL) {
    fprintf(stderr, "malloc(3) has failed !\n");
    exit(1);
  }
  // Fill the array with 1,2,3,4,5,6,7,8
  for (int i = 0; i < 8; ++i) {
    a[i] = i + 1;
  }
  // Compute and print the sum
  printf("sum of a: %d\n", sum(a, a + 8));
  // Free your memory !
  free(a);
  return 0;
}

And we get:

shell> cc -Wall -Wextra -std=c11 -o dyn_arrays dyn_arrays.c 
shell> ./dyn_arrays 
sum of a: 36

Note the test on the return value, malloc(3) can fail, mostly because you don’t have enough memory (or you hit the limit granted to your program by the OS). For various reason, on most modern systems, malloc(3) succeeds in most cases even if not enough memory is available, this is because modern system only binds memory to your program when you concretly access it. But anyway, always check the return value of malloc(3)! (at least in real-life programs)

Other functions related to malloc(3) are calloc(3) and realloc(3):

• calloc(3) is a different interface. It takes a size and a number of objects, and, the most important thing, it ensures that the memory allocated is filled with zeroes beforehand. (it may also check that the product between the size and the number of objects doesn’t overflow or isn’t greater than a possible upper bound).
• realloc(3) is a little bit interesting, it resizes the memory area allocated. In fact, it is not exactly a resize but really is a new allocation. In the general case, it searches for an area of at least the new requested size, copie the content of the old area into it and frees the old area. In some cases it may be able to resize in place. Or fails, like malloc(3).

Examples are often better than words:

#include <stdio.h>
#include <stdlib.h>

struct vector
{
  size_t size, capacity;
  int *data;
};

/*
 * init an already allocated vector
 * with initial size and capacity set to 0
 */
void init_vector(struct vector *this)
{
  this->size = 0;
  this->capacity = 0;
  // capacity 0, then no array so far
  this->data = NULL;
}

/*
 * adds an element at the end of the vector
 * resizes it if necessary
 * we choose to double the size each time
 * returns false if something wrong happen
 */
int vector_push_back(struct vector *this, int x)
{
  if (this->size == this->capacity) {
    int *newdata = realloc(this->data, 2 * (this->capacity + 1) * sizeof (int));
    if (newdata == NULL) {
      // realloc is fair enough to not invalidate data in that case
      return 0;
    }
    this->data = newdata;
    this->capacity = 2 * (this->capacity + 1);
  }
  this->data[this->size] = x;
  this->size += 1;
  return 1;
}

/*
 * resets the vector
 * size and capacity go back to 0
 * data is free, thus the vector can be destroyed transparently
 * ... or reuse ...
 */
void vector_reset(struct vector *this)
{
  free(this->data);
  // Important: otherwise we may try to reuse the invalid address
  this->data = NULL;
  this->capacity = 0;
  this->size = 0;
}

// Demo
int main()
{
  // no need to allocate dynamic memory for the struct, we use it in place
  struct vector vec;
  init_vector(&vec); // now we can use it
  // Add some element
  for (int i = 1; i <= 10; ++i) {
    if (!vector_push_back(&vec, i)) {
      fprintf(stderr, "something goes wrond !\n");
      vector_reset(&vec); // free the memory for us
      exit(1);
    }
  }
  // Print the content
  for (unsigned i = 0; i < vec.size; ++i) {
    printf("%d ", vec.data[i]);
  }
  printf("\n");
  vector_reset(&vec);
  return 0;
}

I let you read, understand and run the code, but here are some important details:

• structs in C are basiccally heterogenous boxes, it is just a way to pack together some values ;
• realloc(3) and free(3) accept null pointers;
• realloc(3) when it fails returns NULL like malloc(3). You need to catch the result before replacing your pointer, otherwise you will loose it.

I opted for a very C++ style here (I know, C++ comes from C, so this is arguably C style too). In particular, the init function doesn’t allocate the structure of the vector, only the data (and in fact, not even the data since we chose to start with an empty vector). This way, we can have a temporary vector on the stack without allocating dynamic memory for it. We only have to care about freeing the inner pointer once we’re done.

One more

There are so many other topics to explore and this post is becoming lengthy. I will play with a last example (the choice was hard…) to illustrate pointer manipulations.

Let’s first start with the notion of linked list. A linked list is a collection of values, a little bit like an array, but with dynamic behaviors. The idea is that rather than storing all the values in a contiguous area, you store them in little boxes (that can be non-contiguous), which are connected by pointers from one to another. This way you can easily add new elements, remove old ones, insert new ones anywhere, etc. all without having to move everything like with arrays to preserve contiguity…

I won’t describe the whole set of list operations, but rather show you a little funny piece of code.

First the definition of list:

// note: this is not the list, but the cell of the list
struct list
{
  struct list *next; // the next element
  int value;         // the data
};

Let’s add some context for my example: you have a list already built, and the pointer to one of the cells. Our task is to detach the cell from the list.

The issue is that in order to do that, we need to find the cell that comes before ours, in order to make its next value point to the target one’s next.

Second problem, if the cell is the first one of the list, we need to update the variable that contains the entry point of the list, otherwise we will end up in an inconsistent state (and probably loose access to the list).

Here is a first naive version:

void detach(struct list **entry, struct list *cell)
{
  // save the previous element
  struct list *prev = NULL;
  for (struct list *it = *entry; it != cell; it = it->next) {
    prev = it;
  }
  // cell is assumed to be in the list
  // so now, prev should point to the element that is just before cell
  // or NULL if cell was the first one
  if (prev == NULL) {
    *entry = cell->next;
  } else {
    prev->next = cell->next;
  }
}

OK, even after removing the comments, this function doesn’t look good. Why? Mostly because there is a if. And worst, the code in both branches is very similar. And there is this story of keeping a pointer to the previous element that is not defined in all cases. Even if it is a rather small function, it contains some traps.

How can we solve that ? Thinking more with pointers! When looking at the final if, we are updating a place containing a pointer, it can be the location containing the entry point or the next field of the previous cell. If we have a pointer to this location, it can contain the address we want ! Here is the code, I let you read it as exercise:

void detach(struct list **entry, struct list *cell)
{
  for (; *entry != cell; entry = &((*entry)->next))
    continue;
  *entry = cell->next;
}

Just a little hint: &((*entry)->next) gives you the address of the field next of the list cell pointed to by the address in entry.

While I really find this version interesting, there is a better trick in some cases. This is pretty good illustration of the principle that states that it is always better to have smart data structures and simpler code.

The idea is that we can have a fake element at the begining of our list, we call that a sentinel. The sentinel never moves, it doesn’t contain a value (or we don’t care about it). This way the empty list is no longer a null pointer but a single element. This also means that when we have to detach the head of the list we always have a previous element! The new code:

void detach(struct list *sentinel, struct list *cell)
{
  for (; sentinel->next != cell; sentinel = sentinel->next)
    continue;
  sentinel->next = cell->next;
}

Elegant, isn’t it ? In fact, the sentinel plays the same role as our double pointer in the previous version.

Goodbye

There is a lot more to tell, but I think that I have covered the important parts of the subject, or at least an important part of the foundations of the subject. I could have spoken about how an allocator works, or how to implement reference counters, or intrusive data structures (I have already done that in my old blog)…

But now it is up to you to practice.

If you’re not a C programmer but survived until here, I hope that you have learned something that could be useful for you and maybe you will try C ?

Where are we going ?

The first question you must consider when building a programming lecture is about your target audience: what do they know, why do they want to learn programming ? I will focus on the classical beginner CS students where a programming lecture will form the fundation of futur software engineers.

At that point, comes the usual discussion about abstraction. Do you need abstraction, do you hide the dirty reality behind high level programming tools ?

That’s not an easy question. More abstraction and higher level tools usualy provide quicker results: your students are able to write code that do interesting things more easily, they may even get shiny little programs they can be proud of. While quick result is often a good source of motivation for students, the easy path is not always the best one.

On the other hand, ‘‘the hard way’’ can be frustrating, most students are not excited by writing programs that print boring numbers on a black and white terminal. But, on the long run, it simplifies the introduction of complex concepts.

But, let’s start now !

The beginning

One of the most difficult task for me, as a teacher, has always be to teach true beginners. It’s very frustrating for a teacher, we always expect that simple concept be simple to teach, but in my own experience, teaching the basis of programming is the most difficult task I’ve ever have.

One of the thing is that programming is not natural for most human, at least, there’s a state of mind that our standard education process does not provide. I have observed on students, that there’s a point where you start looking at the problem in a completely different way and after that point most of the difficulties you had before simply disappear.

The problem for a teacher is that it’s difficult to project yourself on the other side of that point, you’ve cross it a long time ago and now, you can’t imagine that people don’t think in the same way. That’s not specific to programming, we face that kind of issue everyday.

When teaching to beginners, the most important point is push your students as fast as possible on the other side. They’ll only start to learn something once they cross that point.

False simplicity: hidding memory

Functions are one of the most fundamental concepts in programming, the concept is pretty easy to begin with but some complexity can arise as long as you leave the comfortable world of pure functions.

One of the usual issues of students is related to arguments passsing. Let’s illustrate that with a tiny example, a function that fill an array, first in C:

void fill(int t[], size_t len, int val)
{
  for (size_t i = 0; i < len; i++)
    t[i] = val;
}

We can do the same in python:

def fill(t, len, val):
        for i in range(len):
                t[i] = val

Pretty clear, isn’t it. Now, let’s forget C for a while and all you know about pointers, and look at the python code. It seems that we’re able to modify arguments, does it work in any case ? We can test it with a tiny script:

def update(x):
        x += 1
a = 0
print(a)
update(a)
print(a)

This code will only print 0 (twice), the variable is not modify … OK, it’s an integer variable, maybe with a list like in the previous example ? The next example will try to figure it out.

def update2(l):
        l = [1, 2, 3]
t = []
print(t)
update2(t)
print(t)

Oups, again update2 has no effect … If you’re a C programmer, you’ve probably already guessed what’s happening here.

In order to explain this concept to people that have never manipulate memory, pointers or adresses, you’ll need a complex notion of object-reference passing (or whatever you call it). In my experience, students get lost at that point and have a lot of difficulties to handle correctly in which cases arguments can be modified or not.

Now, if your students have been exposed to pointers and memory, you just need to tell them that composed values are manipulated through a pointer, thus when you pass a list, and modify its content you use that pointer but if you replace the list itself, you replace the pointer which is passed by value.

It’s also easier to explain why the following expression doesn’t create the expected matrix:

m = [[0] * cols] * lines

If you don’t know (or don’t see) the problem here: the inner list construction build a list value (thus a pointer) and then the outer construction repeat this value. We then just get a list of lines time the exact same list.

This is an example of the false simplicity behind abstraction, the hard way may seem difficult for the beginner, but it pays more in the long run.

Keep it simple, stupid !

Among mistakes I’ve seen during my teaching years, one of the most difficult to eliminate is what I called ‘‘corner case programming’‘.one of the most difficult to eliminate is what I called ‘‘corner case programming’’.

In short, corner case programming describes the tendency that some students (and even programmers) have to add a lot of tests for useless corner cases. Studying algorithm can help, but it’s an every day fight.

Let’s have a look at some common examples.

Let’s begin with the traditional useless subcases tests. Let’s consider the classic recursive implementation of factoriel with some useless tests:

def fact(n):
        if n == 0:
                return 1
        if n == 1:
                return 1
        return n * fact(n - 1)

This is a pretty stupid version, we can catch both cases with one single test, but it’s not just about gaining few lines, the correct version does less tests at each call, can resist to negative numbers …

def fact(n):
        if n < 2:
                return 1
        return n * fact(n - 1)

Let’s see a similar naive example with an iterative version:

def fact(n):
        if n < 2:
                return 1
        r = 1
        while n > 0:
                r *= n
                n -= 1
        return r

For this version, again, the tests are useless, there’s also a useless loop run (for n == 1), a better version:

def fact(n):
        r = 1
        while n > 1:
            r *= n
            n -= 1
        return r

Of course, these are pretty simple examples, but as I said, we want to eliminate all bad ideas …

Let’s have a look at a more complex example. We consider a classic B-tree implementation (in C) a function that just check if the keys are correctly ordered. For the sake of simplicity, we suppose basic integer keys.

#define RANK ...
struct btree
{
  unsigned nbkeys;
  int keys[RANK * 2 - 1];
  struct btree *children[RANK * 2];
};

int btree_check(struct btree *t, int low, int high)
{
  if (t != NULL) {
    for (unsigned i = 0; i <= t->nbkeys; i++) {
      if (i == 0) {
        if (low > t->keys[i] || (t->children[i] != NULL && !btree_check(t->children[i], low, t->keys[i])))
            return 0;
        continue;
      }
      if (i < t.nbkeys) {
        if (t->keys[i - 1] > t->keys[i] || (t->children[i] != NULL && !btree_check(t->children[i], t->keys[i-1], t->keys[i])))
          return 0;
        continue;
      }
      if (t->keys[i - 1] > high || (t->children[i] != NULL && !btree_check(t->children[i], t->keys[i-1], high)))
        return 0;
    }
  }
  return 1;// An empty B-tree is well ordered
}

This code is inspired from students codes, and in fact, I’ve already simplified part of it …

What are the issues here ? The most obvious problem is the tests on the index inside the loop, this is a classic clue that’s something is going wrong. The second problem is little more subtle: are you shure that code works, does what we expect ? Even if you know the algorithm, it’s difficult to check. And if go a little bit deeper, there’s performance issues also …

Here is a better version:

int btree_check(struct btree *t, int low, int high)
{
  if (t) {
    if (t->keys[0] < low || t->keys[t->nbkeys] > high)
      return 0;
    for (unsigned i = 0; i < t->nbkeys - 1; i++) {
      if (t->keys[i] > t->keys[i + 1])
        return 0;
    }
    if (t->children[0]) {
      for (unsigned i = 0; i < t->nbkeys; i++) {
        if (!btree_check(t->children[i], low, t->keys[i]))
          return 0;
        low = t->keys[i];
      }
      return btree_check(t->children[t->nbkeys], low, high);
    }
  }
  return 1;
}

OK, this looks better, we can still improve some details, but this one is far more acceptable.

What are the important aspect ? We’ve pulled out loop invariants that the compiler can’t detect (in a B-tree, a node as 0 or exactly t->nbkeys+1 children). We’ve split the loop in two, keys and children don’t need the same number of iterations, thus it simpler to have them in separate loops. This is also a performance improvement, since if the keys are not well ordered, we don’t continue in the rest of the tree. There’s still a lot of “if”, but the code is more understandable that way.

One last example, let’s have a look at linked lists. I really like that one, it’s the simplest demonstration that we should prefer smarter data and simpler code. We begin, with a classic implementation of lists of integers with external allocation (list cells are not allocated by the list operations) and we provide two classic operations: a push front and an ordered insert.

struct list
{
  struct list *next;
  int data;
};

void push_front(struct list **list, struct list *elm)
{
  elm->next = *list;
  *list = elm;
}

void insert(struct list **list, struct list *elm)
{
  struct list *cur = *list, *prev = NULL;
  for (; cur && cur->data < elm->data; cur = cur->next)
    prev = cur;
  elm->next = cur;
  if (prev) {
    prev->next = elm;
  } else {
    *list = elm;
  }
}

Now, if we just add a sentinel (you know, that fake cell at the beginning of the lists), we obtain something a little bit simpler:

void push_front(struct list *list, struct list *elm)
{
  elm->next = list->next;
  list->next = elm;
}

void insert(struct list *list, struct list *elm)
{
  for (; list->next && list->next->data < elm->data; list = list->next)
    continue;
  push_front(list, elm);
}

Of course, my first version can be simplified to a similar point (using iteration through double pointer).

One of the idea that I’ve tried to pass to my student, is that when you write some code or design an algorithm, you should always begin with the general case, and then see if some subcases requires some specific code. This is a variation of the classical keep it simple, stupid.

We have various reasons to follow this strategy:

• in most cases, the general case already cover correctly corner cases, adding extra tests is useless and will probably waste computing time;
• since the general case already covers those subcases, the corresponding code is redundant;
• tests for corner cases are often more complex than what it looks like at the beginning, if the corresponding code is specific and works only under the assumptions of that corner case, these tests can introduce subtle bugs;
• redundant code and useless tests make the maintainance of the code more difficult;
• and finally, admit it, we’re lazy and prefer shorter code.

As a teacher, I must admit that I’ve never found the right way to explain this concept. I mean, when I try, they seem to get the point, but fail to apply it in practice. The most effective strategy I found was to show them how their code can be simplified using some form of code review.

Reverse pedagogy

On a less technical side, teachers face another difficulties: students not seeing the interesting aspect of what you’re talking about. This is frustrating, you’ve spent a lot of time building a lecture, finding a way to explain complex notions, and students just don’t care. And worst, later (during project defense for example), they admit that it could have been useful to pay a little more attention …

With other fellow teachers, we’ve discusted that issue a lot of time. One of the idea that finally came out: reverse pedagogy. The idea is to let them try and probably fail first, and then explain them how they should have done it.

I must admit that I haven’t found a correct process, probably because doing it correctly requires an important reconfiguration of the cursus. Anyway, there’s some ideas that can be apply to a programming cursus.

What is also important, is the nature of notions that may benefit from reverse pedagogy. From my own experience, notions related to code organisation, modelisation, project management … Those notions are somehow indirect, you can’t build some simple exercise to demonstrate them.

The after-life

I wrote most of the previous lines when I was about to leave teaching and now it’s done. I think it’s interesting to add a new point of view on the subject.

What was missing in my lectures ? Probably a lot.

First of all, I now see why system programming is probably the most important topic for students. I’ve been teaching it for years, but mostly because I love that. I liked the complexity of interraction with that complex beast, I liked the concept, I liked interracting with low level stuff, I liked digging in the complier behavior …

But what I’ve learnt, with just two months as a real software engineer, is that all those concepts and problems are the most important part of programming. Choosing and implementing an algorithm is most of the time easy, finding the correct datastructure also, but build a complete stuff and make it interracts with the rest of the world are the real difficulties.

Dealing with existing code base, is also a very important experience. Somehow it provides the arguments that I was missing when trying to express some ideas to students. For example, why making code simpler and cleaner is almost as important as making it works. The project I’m on, evolves quickly in rapid envirronment and then have been maintained under the pressure of production. The team I’m working with has a very good software engineering approach based on the concept of done is better than perfect, they push for short term releases which is probably the best strategy, at least for SaaS. The only issue is that it’s difficult to come back to early code, unless it’s broken or we need to modify it in order to include a new feature.

Thus, anything that get release will stay there for a long time, you can’t expect to have anytime to rewrite it. While refactoring is indeed a need, it has the least priority.

In fact, it’s easier to re-engineer your project and modify some design choices than to clean, refactor or rewrite existing code. Which emphasises the importance of writing simple and clean code from the beginning. It also invalidate most software design approach, like complex object oriented beast using inheritance and classes, these designs freeze your code more than anything else.

On the other hand, if you try to build some piece of code that performs simple tasks, one by one, it’s easier to replace them, to combine them or to modify them to meet new goals and provide new features. That’s the essence of the KISS principle and that should be the essence of programming.

Ending words

I must close this article and publish it, even if I could put a lot more material in it. But, it’s better done than perfect. I may come back later on pedgagical subjects, I have a lot more ideas in my mind.

To conclude, spending 15 years teaching programming, algorithms and computer science stuff have been important for me, it was my job, but more than that, it makes me a better programmer, and now I see a future where I can transformed what I’ve learnt into real stuff.

Let’s code !