You know when you work on various projects, and you use various tricks and techniques, and they all seem independent from one another, until the big picture jumps at you and you realize it’s all connected? I experienced this kind of aha moment, that emerged from several (apparently) independent topics I wrote about, a guest post from Miguel Raggi, and my work on three different recent projects. And I wanted to share this moment with you. The common point between those sources is this: if throughout your development process, you think about Usage First, Implementation After, you will maximize y ..read more

Let’s examine another design pattern in our “Design Patterns VS Design Principles” series, where we relate design patterns to design principles. Today, we focus on the Factory method design pattern. We’ll see the various forms the Factory method design pattern can take, the differences with the Abstract Factory method, and to which design principle the Factory method pattern relates to. Design patterns and design principles In case you’re just joining the series, let’s see what we call a design pattern and a design principle. A design pattern is one of the patterns presented in the classic Gan ..read more

There seems to be a problem coming up every so often C++ code: how can an object keep track of a value, given that this value can come from either an lvalue or an rvalue? In short, if we keep the value as a reference then we can’t bind to temporary objects. And if we keep it as a value, we incur unnecessary copies when it is initialized from an lvalue. What’s a C++ programmer to do? There are several ways to cope with this situation. I find that using std::variant offers a good trade-off to have expressive code. Keeping track of a value Here is a more detailed explanation of the problem ..read more

Amongst the many tasks a programmer does, one of them is to add a new feature in a location of the application where there are already many similar exising features. The temptation is then to warm up very specific muscles of our left hand: the pinky muscles that will press on the Ctrl key, the index finger muscles to press on the C key whatever muscles on the right-hand side of our index figer that will move it over the V key. In other words, we prepare ourselves for a copy-paste development. That is, we find something in the application that is similar to what we want to add, copy-paste it ..read more

In the “Design Pattens VS Design Principles” series, we look at design patterns and relate them to design principles. In this episode, we examine the Abstract Factory pattern. Let’s see how Abstract Factory works and what it is useful for, then relate it to a design principle. We will also see a C++ technique to implement Abstract Factory with classes nested in a function. Design Patterns and Design Principles What is the difference between design patterns and design principles? The design patterns we talk about are the collection of patterns described in the popular GoF book: Design patterns ..read more

Generating all the possible combinations from a set of collections and applying a function to each combination is a need that comes up often in programming. This is called a “Cartesian product”. For example, this kind of operation is necessary in the cartesian_product range adaptor, in the cartesian_product pipe, and in the killer feature of verifyAllCombinations in the ApprovalTest.cpp library, to cite just a few. The most basic usage of a Cartesian product looks like this: auto const inputs1 = std::vector<int> {1, 2, 3}; auto const inputs2 = std::vector<std::string>{"up ..read more

A Cartesian product consists in applying a function to all the possible combinations of the elements of several collections. For example, consider the three following collections: auto const inputs1 = std::vector<int> {1, 2, 3}; auto const inputs2 = std::vector<std::string>{"up", "down"}; auto const inputs3 = std::vector<std::string>{"blue", "red"}; Then (2, up, blue) and (3, up, red) are two of the possible combinations of elements from those three collections. In total, there are 3*2*2, that is 12 possible combinations. If we apply the following function to each ..read more

Error handling is a tricky part of software programming. It’s tricky in several aspects: it’s difficult to get right, and it can make code less expressive. But it doesn’t always have to be that way. Sometimes asking the question “how can we prevent the error from happening in the first place?” can avoid the need for error handling altogether. Why handling errors is difficult Several things make error handling in code difficult. We haven’t got the right tool yet If you look back on the history of C++, the number of tools for errors handling has been growing at a steady pace. C used error numbe ..read more

In today’s episode of the series “Design Pattens VS Design Principles”, we’re focusing on the last behavioural design pattern: Visitor, and see how it relates to the High Cohesion design principle. The GoF meets the GRASP If you’re just joining the series, The GoF meets the GRASP is about relating each of the GoF design patterns with one of the 9 GRASP design principles. GoF design patterns are the 23 patterns in the hugely popular Design Patterns book: GRASP design principles are higher level principles that are explained in Craig Larman’s Applying UML and Patterns: The 9 GRASP design princ ..read more

Warning: this post gets into a very opinionated subject. You may agree with some points, you may disagree with others, it may trigger controversy, and you may be tempted to seize your keyboard to tell how you have a completely different view on programming. This is exactly what I want you to do. Rather than pouring down my opinions, my point is to ignite a debate with you on how to use programming paradigms to write expressive code. In fact, as you’ll see, I will largely quote the opinions of some other people I had the chance to watch or talk to. There is no right or wrong answer so please, l ..read more