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”
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++.
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.
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”
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.
May the FORs leave you alone
In his post may the FORs be with you, Michael mentioned that it’s best to avoid handwritten loops at all. This is not self explanatory for a lot of people, and while many arguments can be put forth to support the use of algorithms, in this post let’s stick with one: readabilty.
Continue reading “May the FORs leave you alone”
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.
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.
Expressing preconditions with invariants of parameter types
Everyone who has read Scott Meyer’s books knows: it is a good idea to make your code easy to use correctly and difficult to use incorrectly. In this light, we may be able to improve on the ifs we routinely use to check our functions’ preconditions.
The basic idea is to remove all the ifs that check for error conditions at the beginning of your function’s body by providing type parameters that already give sufficiently strong guarantees.
Continue reading “Expressing preconditions with invariants of parameter types”