michael – Clean C++

2013-06-30

Interfaces done right

Interfaces are one of the backbones of modern, object-oriented design. You need to use instances of different classes which share similarities in a uniform way? Use interfaces. You cannot easily test a class because it depends on details of other classes? Make your class depend on interfaces instead and introduce mock objects. You have a class with a single responsibility, but a respectable amount of methods which are intended for different types of callers? Make your class implement several interfaces, and let different callers refer to the ones which suit their needs.

As you can see, interfaces used correctly are pretty powerful tools, and many programming languages such as Java and C# provide dedicated interface keywords. This is not the case for C++. This article explains how to write clean and safe interfaces for your classes.

Continue reading “Interfaces done right”

2013-03-07

Code Dojo: Hangman

Hangman is a little game often played by pupils during math lessons without the teacher knowing. The rules are quite simple: The game master thinks of a word or phrase. The players try to guess the solution in a letter-by-letter fashion. For any bad guess, the game master adds another piece to a drawn gallows, complete with unfortunate hangman and other accessoires. When the gallows is fully constructed, the players lose. Obviously, players win if they are able to correctly solve the puzzle before.

Because of its simplicity, hangman is ideally suited for learning test-driven development or as a task for code dojos. Try to write classes and functions to handle the game logic. These features should be designed to be easily usable in an actual game application.

Continue reading “Code Dojo: Hangman”

2013-02-26

Code Dojos

Learning continuously is important in our rapidly changing business to avoid being outlived by the latest technology or style. I guess most of our readers come to clean-cpp.org because they are interested to learn something new about C++ they did not know before, or they like the good feeling to read that someone else thinks what they are already doing is right. Besides reading blogs and books, there are a few things one can do to stay up to speed:

Write a blog on your own. You would be surprised what you need to learn in order to write an article.
Visit talks or watch them on Youtube or other video platforms.
Join an open source community and start working on a project you like.
Learn a new programming language.
Browse through someone else’s code.
Talk to someone who is a better programmer than you are.

A code dojo is a relatively new practice of learning from another, and it combines some of the best features of above list. Basically, it is an informal gathering of programmers. Together, they write code to solve a fun task. They talk with each other, drink beer, and eat pizza. It is almost like a night out, but with more code.

Continue reading “Code Dojos”

2013-02-11

Mock objects

Unit tests follow a simple pattern. First, you create a controlled environment for the function or class you want to test. Afterwards, you call a function or method of an object or create a new instance. Finally, you assert that the function returns the expected value or the state of your object has changed as desired. Sometimes, though, tests seem to grow unnaturally large because it is ridiculously difficult to control the environment.

Quite often the issue is that the code you would like to test is too specialized to be easily testable. In this article we will learn about how interfaces and mock objects can be used to enhance the testability of your code and make it easier to reuse.

Continue reading “Mock objects”

2013-02-05

Test-driven development

In an earlier article I discussed the merits of unit tests. In essence, unit tests are pieces of code which assert that your production code works as intended. With a sufficient amount of unit tests it is possible to refactor your production code at any time, because the safety net of knowing when you broke something gives you courage.

Typically, programmers write code and test it afterwards. Code which is not easily unit testable is not tested or integration tested. Execution paths are overlooked, boundary cases get ignored. There is not much safety for future changes, because there is no machine-executable specification of how less well-known regions of the code are supposed to behave. Enter test-driven development (TDD).

Continue reading “Test-driven development”

2013-01-27

Unit tests

Most programmers have heard of unit tests. Many programmers regularly write unit tests, even though it should be all of them. Some even work with test-driven development, and this should be all of them, too. So, what are unit tests? Unit tests are the safety net which protects you from fixing critical bugs in the night after the release. They are your code’s lawyers and prove its innocence. Unit tests form the shiny armor which gives you courage before the battle of refactoring. Unit tests are the pillow which lets you find an untroubled sleep. In short, unit tests are invaluable tools for software development. This article presents some strategies how unit tests can be implemented in C++.

Continue reading “Unit tests”

2013-01-20

Mandatory template arguments

Consider the following function declaration:

template <typename ... Items_To_Print>
void print_as_csv(std::ostream & stream, char delimiter, Items_To_Print && ... items_to_print);

Though the declaration may seem rather involved, the actual application of this function is quite simple:

print_as_csv(std::cout, ';', 2.0, 42, "hello");

The compiler knows how to create an instance of print_as_csv by a mechanism called template argument deduction. It works only for functions, because the compiler needs arguments to deduce the types from. There are, however, template functions for which not all template arguments can be deduced by the compiler.

Continue reading “Mandatory template arguments”

2013-01-16

Foobar names

foobar is a term one often encounters when searching the web for tutorials on programming. What it is supposed to mean is not really clear; some people, though, claim that it stems from the German word furchtbar, which translates as horrible. I am no authority on etymology, but whenever I see a tutorial using foo and bar as variable names, I think furchtbar is quite fitting.

Continue reading “Foobar names”

2013-01-09

I like to std::move it

A little while ago while I was surfing the web I stumbled on a blog of a C++ programmer. Sadly, I was unable to retrace my steps, so I will have to reconstruct what I found there from memory. The programmer was faced with the task of multiplying two matrices with each other. The result is yet another matrix. Efficiency and ease of use were important criteria. Here is the relevant part of the code:

matrix & matrix::operator* (matrix const & other) const
{
	// snip: ... assert matrix sizes are compatible ...
	matrix * result = new matrix(rows(), other.columns());
	// snip: ... compute and store matrix elements ...
	return *result;
}

Let us put on our CSI C++ hat for a while.

Continue reading “I like to std::move it”

2013-01-06

May the FORs be with you

Loops are among the basic constructs you find in nearly all programming languages. Of the available variations, for loops are the most common ones. The word for is so small that it is not affected by the tax on long keywords and variable names that programming languages seem to be subject of. Thus, you will find for as a keyword in most of them.

C++11 supports a multitude of styles to write for loops. Let us have a look at some of these possibilities for a simple example.

Continue reading “May the FORs be with you”