Clean C++ – Clean Software Development with Modern 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-30

Assignment operators in C++11

Move Semantics are a game changer on how we return values and pass arguments in C++11. In this post we concern ourselves with the best way to implement an assignment (‘=‘) operator. If rvalues and move semantics are all new for you, you might want to read Michael’s post I like to std::move it first.
Continue reading “Assignment operators in C++11”

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-23

Adaptors

In May the FORs leave you alone we replaced manual loops with calls to algorithms. For this we did not use the algorithms provided by the standard library but used boost.Range instead. In this post I’ll give you the rationale for that decision and introduce the transformed adaptor into the linear regression example.

Continue reading “Adaptors”

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”