In Part 3 we expanded on the original buffer and it now supports any type and any size. Our RingBuffer almost behaves like any of the STL types, such as std::vector and I say almost. Consider the following code:

int main()
{
    RingBuffer<int, 10> my_buffer;
    for (int i = 0; i < 10; ++i)
    {
        my_buffer.push_back(i);
    }

    for (auto x : my_buffer)       // This line produces an error.
    {
        std::cout << x << ' ';
    }
}

This code should work, but if we actually try to run it we will get a compiler error.

In Part 2 we built a buffer that works, however it is stuck with unsigned int and size 8, but what if we wanted to use it with std::string or custom types like game events, or only store the last 4 frames? Do we write a buffer per class? We could, but that would be a nightmare, wouldn’t it?

Meet Templates

In C++, templates are a powerful mechanism for generating code. A template is a blueprint that the compiler uses to generate actual code. Think about it this way, a class is a blueprint for a thing (a type of thing), templates are blueprints for classes.

In Part 1 we covered the fundamental building blocks: classes, functions, constructors and how to organize code into header and implementation files. We created a simple Person class to illustrate these concepts and now it is time to apply what we learned to our main project: The RingBuffer. Remember, our ring buffer needs to do a few key things: store elements, track where to add the next one, and know when it’s full. Let’s begin by creating a class.

Hello! If you recall from the previous series, we built a program that handled text input, stored numbers into a vector and performed calculations. However there were some concepts in there that we used, but that I didn’t really explain. I am referring to iterators. In this new series I aim to go over what they are, how they work and how to use them, so get ready because it will be a bumpy ride and as usual, we will have to build our way there because fundamentals are always important.

In Part 2 we covered some basic principles about standard input in C++, we talked about the input buffer stream, the iostate and some mechanisms that the C++ programming language provides us with to get input from users. We ended with a program that takes input from users and stores them, but that had the fatal flaw of only being able to store a single number, which really doesn’t make for a good calculator, does it? So here are a few changes.

In Part 1 of this series I covered some C++ fundamentals by building a small unit converter. While the program worked, it had a critical weakness: it assumed the “happy path,” where users never make mistakes. In the real world, things are messy, and as programmers, we have to anticipate how our applications might fail. We can’t predict everything, but we can certainly guard against the most common issues.

In your programming journey, have you ever reached a point where you feel overwhelmed with everything a language can do, leaving you unsure of what to learn first or which features are truly important? I find myself in that exact situation. With each new C++ standard, I feel like I’m falling behind. Here we are in 2025, and I’m still trying to master move semantics and how to best use smart pointers. Learning a language with a rich history like C++ can be grueling. I’ve noticed I often get mesmerized by what’s new, shiny, and exciting, causing me to neglect the fundamentals. That’s what this post is about: practicing some of the fundamentals of the language and its standard library. In this new series, I will explore the basics of the <iostream> library.