Some general-purpose algorithms accept a range (e.g. two iterators) and an additional value. For example std::iota fills the specified range with sequentially increasing values, starting with a certain value V and repetitively evaluating ++V:


vector<int> aVector (5);

iota ( begin(aVector), end(aVector), 1);

// aVector is {1, 2, 3, 4, 5}

This algorithm is really simple, but how is it possible to operate on the initial value in a quite generic way? Suppose we want to reuse iota to fill the range with increasing squared values, e.g.: {1, 4, 9, 16, 25}.

Since iota accepts nothing but a value in the range, we cannot pass, say, a lambda. We have to feed it with a special value or something like that. A mimesis object (explained in Advanced C++ Metaprogramming, by Davide Di Gennaro) is something we may take inspiration from. Actually, according to Davide’s definition, a mimesis for a type T is a unary predicate that behaves like an instance of T. It generally implements operator==(const T&), operator!=(const T&) and operator “cast to T”. In other words if M is a mimesis for type T, then the fundamental property for M is:


M<T> m;

assert(m == static_cast<T>(m));

A simple example is a mimesis that identifies positive numbers:


template <typename scalar_t>;
struct positive
{
 bool operator==(const scalar_t& x) const
 {
    return x>0;
 }

 operator scalar_t() const
 {
    return 1; // an arbitrary positive number
 }
};

template <typename scalar_t>;
inline bool operator==(const scalar_t& x, const positive<scalar_t>& p)
{
    return p == x;
}

...
double arr[] = {-1.0, 2.5, 5.0};
auto it = std::find(arr, arr + 3, positive<double>()); // 2.5

With mimesis, we could unify algorithms (e.g. in the previous example we don’t need find_if anymore). You’re right, a mimesis takes more effort than a lambda, but it’s worth especially for generalizing functions that take a special value as an argument (I suggest you to read, for example, the “End of range” section in Davide’s book).

Ok, this was a very short intro. Back to our problem: How to use mimesis to generalize iota? Let’s have a look at a possible implementation of iota:

template<class ForwardIterator, class T>
void iota(ForwardIterator first, ForwardIterator last, T value)
{
    while(first != last) {
        *first++ = value;
        ++value; // pre-increment operator
    }
}

Suppose value is a mimesis that initially stores a certain int (say 1). The mimesis have to be able to perform two operations:

  • pre-increment (for line 6)
  • cast to int (for line 5)

My idea is to create a generic mimesis “holder” for iota that receives a function that performs the user’s operation, and which result will be casted to T (but you can extend it, for example, by providing also a pre-increment function):


template<typename T, typename MainFn>
struct iota_mimesis_t : MainFn
{
 template<typename TT, typename FF>;
 iota_mimesis_t(TT&& aValue, FF&& aMainFn)
    : MainFn(forward<FF>(aMainFn)), value(forward<TT>(aValue))
 {}

iota_mimesis_t& operator++()
 {
    ++value; // can be generalized
    return *this;
 }

 operator T()
 {
    return MainFn::operator()(value);
 }

 T value;
};

template<typename T, typename F>
iota_mimesis_t<T,F> iota_mimesis(T&& value, F&& fn)
{
 return iota_mimesis_t<T,F>(forward<T>(value), forward<F>(fn));
}

...

vector<int> v (5);
iota ( begin(v), end(v), iota_mimesis(1, [](int anInt){ return anInt*anInt; }));
// aVector is {1, 4, 9, 16, 25}

The key point here is to grasp the internals of iota (that are easy). Different algorithms could be more complicated, but often it’s worth striving to generalize some stuff. Mimesis could be precious allies to deal with “value-only” algorithms (think of legacy code also) and mixing them with modern lambdas can generalize even further.

This succint post is just an introduction. If you spot “lambda-unable” algorithms, try to make them “lambda-able” with mimes and be generic!

This post is basically a meditation on static design choices and code expressivity.

Some days ago I was writing a simple wrapper around std::map supporting a couple of elemental features:

  • succinct syntax for inserting/updating key-value elements, e.g.:

selector<string, int> sel;

sel.at("one") = 1; // insertion

sel.at("two") = 2; // insertion

sel.at("one") = 10; // update

sel.get("one"); // 10

  • mechanism to handle a possible default value if an inexistent key is looked up.

Note that possible means optional and the client should be able to choose either to provide a default value or not. If a default value is not provided, the get() method just throws. From an Object-Oriented standpoint, a simple way to deal with this requirement is to have an interface, say IDefaultValueProvider<T>, and two concrete classes, say ActiveDefaultValueProvider<T> and PassiveDefaultValueProvider<T> (sort of Null Object Pattern).

Our selector<K,T> will store a unique_ptr<IDefaultValueProvider<T>>, passed in the constructor. Something like:


selector<string, int> sel ( make_unique<ActiveDefaultValueProvider<int>(0) );

sel.at("one") = 1; // insertion

sel.get("one"); // 1

sel.get("foo"); // 0 (default)

selector<string, int> sel_nd ( make_unique<PassiveDefaultValueProvider<int>() );
// or just selector<string, int> sel_nd; // default-parameter

sel_nd.get("one"); // throws

Ok this works. How does this implementation cost?

  • we wrote an interface and two concrete classes
  • we need a dynamic allocation (unique_ptr)
  • the selector has to store a unique_ptr
  • defaulted-selector and non-defaulted-selector have the same type

The latter point leads to (probably) the most important issue: we don’t know what will happen when selector.get() is called. Will it throw? Will not? Should we flood our code with plenty of try/catch? To solve this problem we can, for example, change the return value of get(): instead of getting a T&, we can return a pair<bool, T&> where the first element is true if the key exists and the second is the value corresponding to that key (if the key does not exist, T& is binded to a global fake T).

Ugly.

We can do better, but does it make sense? I think no. This problem can be addressed from another perspective: the client must decide which type of selector she wants, if a defaulted one or not. This way the user will know exactly what will happen. When designing classes it is important to discern between static and dynamic abstractions. Think of “configurability”: does it make sense to configure a certain instance of a class at compile-time (e.g. using a template) or at run-time (e.g. reading from a file)? For my simple example, the answer is probably the first.

Ok, how to express this static choice? An idea is to use templates and this is the second part of my meditation: how to communicate our intentions effectively? In particular, what if the readers (e.g. maintainers) of our code are not very familiar with TMP? I’d like to find a middle way combining compactness and clarity.

The problem now is: a selector must be instantiated by providing a template parameter, say either enable_default or disable_default. What we expect:


selector<string, int, enable_default> sel1 (10); // default = 10

selector<string, int, enable_default> sel2; // compile-error (default not provided)

selector<string, int, disable_default> sel3; // ok

selector<string, int, disable_default> sel4 (20); // compile-error

Suppose enable_default and disable_default are boolean flags (respectively, true and false). We have at least two possibilities here:

  • write two specializations (verbose but quite clear)
  • use static_assert and a bit of metaprogramming:
#include <type_traits>

template<typename K, typename T, bool flag>
struct selector
{
  template<typename V>
  selector(V&& pDefault) : default_value(std::forward<V>(pDefault))
  {
    // if (flag == true) OK, else ERROR (and complain)
    static_assert(flag, "Default value unexpected");
  }

  selector() : default_value(1)
  {
    // if (flag == false) OK, else ERROR (and complain)
    static_assert(!flag, "Provide a default value");
  }

private:

   // if (flag == true) T, else char (a fake default)
   typename std::conditional<flag, T, char>::type default_value;

// ... implementation ...
};

This is more readable and clearer than lots of enable_if and other tricks. But we can do much better by using Policy-Based Design and   moving the (single) point of variation to real classes (our policies). We’ll get rid of static_asserts and std::conditional.

This is a possible draft:

template<typename T>
struct disable_default
{
  T& get_default()
  {
    throw 1;
  }

  const T& get_default() const
  {
    throw 1;
  }
};

template<typename T>
struct enable_default
{
  template<typename Value>
  enable_default(Value&& def_value) : default_value(std::forward<Value>(def_value))
  {
  }

  const T& get_default() const
  {
     return default_value;
  }

  T& get_default()
  {
     return default_value;
  }

private:
  T default_value;
};

template<typename K, typename T, template <typename> class default_policy = enable_default>
struct selector : public default_policy<T>
{

 using typename default_policy<T>::get_default;

 template<typename Value>
 selector(Value&& def_value) : default_policy<T>(std::forward<Value>(def_value))
 {
 }

 selector()
 {
 }

 T& select(const K& key)
 {
   return const_cast<T&>(static_cast<const selector*>(this)->select(key));
 }

 const T& select(const K& key) const
 {
   auto it = selector_map.find(key);
   if ( it != end(selector_map) )
   {
      return it->second;
   }
   else
   {
      return get_default();
   }
 }

//... other stuff omitted here ...

private:
   std::map<K,T> selector_map;
};

Let’s see how to instantiate selectors:

selector<string, int, enable_default> def_selector(0);

//...

selector<string, int, disable_default> ndef_selector;

A possible (and a bit different) code is on ideone.

A couple of notes:

  • the policy is a “template template parameter” to avoid redundancy
  • a constructor is not generated if not used (e.g. using enable_default, the empty ctor is not generated at all)

The mechanism is clear because it is sort of driven by design: enable_default wants to be constructed with an argument, then the host class (the selector) just forwards its constructor parameter to the base class. If the user does not provide a parameter, the code simply does not compile. If the code is not easy to read yet, put a static_assert (or a comment) to clarify our intentions, but I think it’s not needed.

My final note about this meditation is: template metaprogramming aims to be clear and helpful instead of tricky and painful. We have lots of possible solutions, more or less complicated. Policy-Based Design is not only a usage of templates, but also a tool for specifying constraints, class rules, and (static) abstractions. It helps to express choices by (static) design.

I conclude with a question for you about expressivity/clarity: given, for example, this code I wrote in a previous post to force the user to pass an rvalue-reference:


// [1] (does not compile on VC2010)
template<typename T>
auto make_move_on_copy(T&& aValue)
 -> typename enable_if<is_rvalue_reference<decltype(aValue)>::value, move_on_copy<T>>::type
{
    return move_on_copy<T>(move(aValue));
}

// [2]
template<typename T>
move_on_copy<T> make_move_on_copy(T&& aValue)
{
   static_assert(is_rvalue_reference<decltype(aValue)>::value, "parameter should be an rvalue");
   return move_on_copy<T>(move(aValue));
}

I think SFINAE here is overused, whereas static_assert is easier and more readable. Which do you prefer?

C++11 introduces the concept of range-based for loop to iterate over data structures such as STL containers:

vector<int> aVector {1, 2, 3, 4, 5};

for (auto i : aVector)
{
   cout << i << " ";
}

Thanks to lambda expressions, the code above may be considered just a syntactical simplification to:

for_each( begin(aVector), end(aVector), [](int i)
{
   cout << i << " ";
});

Looking at this code, how is it possible to iterate over more than one container at the same time? I mean something like this:

list<float> aList {6.1, 7.2, 8.3, 9.4, 10.5};

for_each( aVector, aList, [](int i, float f)
{
   cout << i << " " << f << endl;
});

We could use smart libraries such as Boost.Fusion to achieve similar results, but suppose we cannot use anything but C++11 capabilities.

Here I’m going to show you a possbile way to iterate over several ranges with the same syntax of for_each. Along the way, some reusable utilities will be presented.

To start, this is the simplest implementation of for_each you can find:

template<typename InputIterator, typename Callable>
Callable for_each(InputIterator begin, InputIterator end, Callable fn)
{
   for( ; begin != end; ++begin)
   {
     fn (*begin);
   }
   return fn;
}

My idea is to employ a couple of tuples: the first containing all the begin-InputIterators, the second containing all the end-InputIterators. For instance:

vector<int> aVector;
list<float> aList;
map<string, int> aMap;

auto begins = make_tuple(begin(aVector), begin(aList), begin(aMap));
auto ends = make_tuple(end(aVector), end(aList), end(aMap));

// i-th range: [get<i>(begins), get<i>(ends)]

So, for_each_multi has the following signature:

template<typename Tuple, typename Callable>
Callable for_each_multi(Tuple begins, Tuple ends, Callable fn);

Considering the simplest for_each implementation, we need three basic building bricks:

  1. check that begin != end (for each [begin, end] range)
  2. ++begin (for each begin)
  3. fn (*begin) (simultaneously for each begin)

Good news: 1 and 2 fall in the same support function that I called visit_tuple. This is just an “apply to all” for tuples that applies a function to each element of a tuple. Generalizing, visit_tuple receives any number N of tuples and a callable object having a function call operator which accepts N parameters.

For example, if we call visit_tuple with one tuple, the function call operator will be required to be single-argument; otherwise, passing two tuples, a two-arguments function call operator will be needed, etc.

My implementation is a bit verbose but I find it more readable. visit_tuple uses a support struct that makes the recursion and goes through each element of the tuple(s):

// visit_tuple
template<typename Callable, typename Head, typename... Tail>
Callable visit_tuple(Callable f, Head&& aTuple, Tail&& ...aTail)
{
   const size_t size = std::tuple_size<typename std::remove_reference<Head>::type>::value-1;
   visit_tuple_ws<size>::visit(f, aTuple, aTail...);
   return f;
}

// support struct to iterate over the tuple(s)
template<size_t size>
struct visit_tuple_ws
{
   template<typename Callable, typename Head, typename... Tail>
   static void visit(Callable& f, Head& aTuple, Tail& ...aTail)
   {
      visit_tuple_ws<size-1>::visit(f, aTuple, aTail...);
      f(std::get<size>(aTuple), std::get<size>(aTail)...);
   }
};

// stop recursion here
template<>
struct visit_tuple_ws<0u>
{
   template<typename Callable, typename Head, typename... Tail>
   static void visit(Callable& f, Head& aTuple, Tail& ...aTail)
   {
      f(std::get<0>(aTuple), std::get<0>(aTail)...);
   }
};

I know there are several ways to make this code less verbose (maybe the support struct can be eliminated), I repeat this style may be more readable in some contexts.

Just for trying, printing a tuple is probably the easiest usage of this function. The code is straightforward:

struct Printer
{
   // generic function call operator
   template<typename T>
   void operator()(T&& t)
   {
     cout << t << " ";
   }
};

// print!
visit_tuple( Printer(), make_tuple(1, 5.0, "Hello") );

Being first-class objects, functors can be passed to and returned from functions (maintaing a state). Let’s write a simple functor that checks begin != end:

struct CheckBeginEnd
{
   CheckBeginEnd() : BeginIsNotEnd(true) {}

   template<typename T>
   void operator()(T&& begin, T&& end)
   {
     BeginIsNotEnd &= (begin != end);
   }

   bool BeginIsNotEnd;
};

Incrementing is even simpler:


struct Increment
{
   template <typename T>
   void operator()(T&& t)
   {
      ++t;
   }
};

So we completed the first part of for_each_multi:

// for_each_multi
template<typename Tuple, typename Callable>
Callable for_each_multi(Tuple begins, Tuple ends, Callable fn)
{
 for ( ; visit_tuple(CheckBeginEnd(), begins, ends).BeginIsNotEnd;
       visit_tuple(Increment(), begins) )
  {...apply...}

 return fn;
}

The “apply” part of the algorithm is a bit more difficult because it requires tuple unpacking. The problem is general and the solution I propose can be reused. Unpacking is presented below:

unpack

Basically, given a function Fn and a tuple, an unpacker is able to call Fn passing the content of the tuple as parameters.

Our case is slightly different because we need to dereference each parameter before passing it to Fn. This fact encouraged me to be more generic, as you’re going to discover.

So, is it clear why we need unpacking? If no, suppose to have these ranges and this lambda:

auto begins = make_tuple(begin(aVector), begin(aList));
auto ends = make_tuple(end(aVector), end(aList));
auto fn = [](int anInt, float aFloat) { ... }

At some point we’ll have to call something like:

fn ( get<0>(begins), get<1>(begins) )

We need to call fn using begins’ content as parameter. Generalizing:

auto begins = make_tuple(begin(aVector), begin(aList), ...);
auto ends = make_tuple(end(aVector), end(aList), ...);
auto fn = [](int anInt, float aFloat, ...) { ... }

...

fn ( get<0>(begins), get<1>(begins), ..., get<size-1>(begins) )

And this is precisely the unpacker job!

To Write an unpacker, the role of variadics is pivotal. Consider what this trivial piece of code does:


template<size_t S, typename T>
void apply_one_element(T&& aTuple)
{
   my_function( std::get<S>(aTuple) );
}

Calls my_function passing the S-th element of aTuple as parameter. This can be generalized to:


template<size_t ...S, typename T>
void apply_more_element(T&& aTuple)
{
   my_function( std::get<S>(aTuple) ... );
}

apply_more_element<0u, 1u, 2u> ( make_tuple(1, 2.0, "hello") );

The last line could be considered expanded to:


template<0u, 1u, 2u, typename T>
void apply_more_element(T&& aTuple)
{
   my_function( std::get<0u>(aTuple), std::get<1u>(aTuple), std::get<2u>(aTuple) );
}

If it was (sort of) automatic, it would be exactly what we need: we want a way to generate the size_t sequence from 0 to tuple_size – 1.

This can be done using a couple of support types: one that carries the sequence around and another one that generates it. The former is simple:

template<size_t ...>
struct sequence {};

So a possible unpacker may be written like:

struct Unpack
{
   template< typename Callable, typename Tuple, size_t ...S >
   static void unpackAndApply(Tuple&& tuple, Callable& fn, sequence<S...> )
   {
     fn(std::get<S>(tuple) ...);
   }
};

sequence<S…> is used just to carry around the size_t sequence. Now, the harder part. How to generate sequence<S…>? For example: given tuple<int, float, string>, we want to create sequence<0, 1, 2>. 

A possible implementation is:

template<size_t N, size_t ...S>
struct generate : generate<N-1u, N-1u, S...> {};

template<size_t ...S>
struct generate<0u, S...>
{
   typedef sequence<S...> type;
};

Considering N=3, I hope the idea will become clearer through this figure:

generate

If you have understood the transition from generate<2,2> to generate<1,1,2> then you have won!

The last part of for_each_multi consists of the apply_tuple function:

// apply_tuple
template<typename Unpacker, typename Tuple, typename Callable>
void apply_tuple(Tuple&& tuple, Callable&& fn)
{
   const int size = std::tuple_size<typename std::remove_reference<Tuple>::type>::value;
   Unpacker::apply( std::forward<Tuple>(tuple), std::forward<Callable>(fn), typename generate<size>::type() );
}

The Unpacker template parameter is just a sort of policy that handles how the parameters are passed to the callable object. In our case, we have to implement a sort of “dereferencer unpacker”:

struct Dereference
{
   template< typename Callable, typename Tuple, size_t ...S >
   static void apply(Tuple&& tuple, Callable& fn, sequence<S...> )
   {
     fn(*std::get<S>(tuple) ...); // aka fn(*it)
   }
};

And finally for_each_multi takes this form:

// for_each_multi
template<typename Tuple, typename Callable>
Callable for_each_multi(Tuple begins, Tuple ends, Callable fn)
{
 for ( ; visit_tuple(CheckBeginEnd(), begins, ends).BeginIsNotEnd;
         visit_tuple(Increment(), begins) )
 {
   apply_tuple<Dereference>(begins, fn);
 }

 return fn;
}

An example of usage:

vector<int> aVector {1, 2, 3, 4};
array<string, 4> anArray("one", "two", "three", "four");

for_each_multi(
   make_tuple(begin(aVector), begin(anArray),
   make_tuple(end(aVector), end(anArray),
   [](int i, const string& s)
   {
     cout << i << " is " << s << endl;
   }
);

To reduce verbiage, if you need to iterate over full ranges (e.g. begin-end) , I propose a couple of possible utilities:

// begins tuple
template<typename Head, typename ...Tail>
auto begins(Head&& head, Tail&& ...tail)
-> decltype(make_tuple(begin(head), begin(tail)...))
{
return make_tuple(begin(head), begin(tail)...);
}

// ends tuple
template<typename Head, typename ...Tail>
auto ends(Head&& head, Tail&& ...tail)
-> decltype(make_tuple(end(head), end(tail)...))
{
return make_tuple(end(head), end(tail)...);
}

Followed by:

#define ON(...) begins(__VA_ARGS__), ends(__VA_ARGS__)

Now we can write:

for_each_multi( ON(aVector, anArray), [](int i, const string& s)
   {
     cout << i << " is " << s << endl;
   }
);

Without adding any support functions nor macros, another version (that I like a bit less because you have to put the callable before the containers) could be:

template<typename Callable, typename Head, typename... Tail>
Callable for_each_multi(Callable fn, Head&& head, Tail&& ...tail)
{
   return for_each_multi(
     std::make_tuple(begin(head), begin(tail)...),
     std::make_tuple(end(head), end(tail)...),
   fn);
}

...

for_each_multi([](int i, const string& s)
{
   cout << i << " is " << s << endl;
}, aVector, anArray);

As usual, my code is on ideone (just a note: begin/end non-members are not supported so I had to use .begin()/.end() member-functions).

It’s presumable the existence of other smarter (and shorter) ways to accomplish the same target, but I hope this post can be useful to play a bit with tuples and variadics. At least I enjoyed a lot writing this stuff!

I think one of the most attractive feature of C++11 is about lambdas. They simplify and encourage the usage of STL algorithms more than before, and they (may) increase programmers productivity. Lambdas combine the benefits of function pointers and function objects: like function objects, lambdas are flexible and can maintain state, but unlike function objects, their compact syntax don’t require a class definition.

The syntax is simple:

auto aLambda = [ ] ( const string& name ) { cout << "hello " << name << endl; }
aLambda("Marco"); // prints "hello Marco"

The code above defines a lambda with no return value and receiving a const string& parameter. What about the “[ ]“? That identifier is the capture specification and tells the compiler we’re creating a lambda expression. As you know, inside the square brakets you can “capture” variables from the outside (the scope where the lambda is created). C++ provides two ways of capturing: by copy and by reference. For example:

string name = "Marco";
auto anotherLambda = [name] { cout << "hello " << name << endl; }
anotherLambda(); // prints "hello Marco"

This way the string is copied into the state of anotherLambda, so it stays alive until anotherLambda goes out of scope (note: you can omit the brackets if the lambda has no parameters). Differently:

string name = "Marco";
auto anotherLambda = [&name] () { cout << "hello " << name << endl; }
anotherLambda(); // prints "hello Marco"

The only difference is the way we capture the string name: this time we do by reference, so no copy is involved and the behavior is like passing a variable by reference. Obviously, if name is destroyed before the lambda is executed (or just before name is used): boom!

After this introduction, in this post  I’m going to discuss about an issue on capturing I encountered few days ago at work: what if I want to capture by moving an object instead of both copying and referencing? Consider this plausible scenario:

function<void()> CreateLambda()
{
   vector<HugeObject> hugeObj;
   // ...preparation of hugeObj...

   auto toReturn = [hugeObj] { ...operate on hugeObj... };
   return toReturn;
}

This fragment of code prepares a vector of HugeObject (e.g. expensive to copy) and returns a lambda which uses this vector (the vector is captured by copy because it goes out of scope when the lambda is returned). Can we do better?

Yes, of course we can!” – I heard. “We can use a shared_ptr to reference-count the vector and avoid copying it“:

function<void()> CreateLambda()
{
   shared_ptr<vector<HugeObject>> hugeObj(new vector<HugeObject>());
   // ...preparation of hugeObj...

   auto toReturn = [hugeObj] { ...operate on hugeObj via shared_ptr... };
   return toReturn;
}

I honestly don’t like the use of shared_ptr here but this should work well. The subtle (possible) aspect of this attempt is about style and clarity: why is the ownership shared? Why can’t I treat hugeObj as a temporary to move “inside” the lambda? I think that using a sharing mechanism here is like a hack to fill a gap of the language. I don’t want the lambda to share hugeObj with the outside, I’d like to “prevent” this:

function<void()> CreateLambda()
{
   shared_ptr<vector<HugeObject>> hugeObj(new vector<HugeObject>());
   // ...preparation of hugeObj...

   auto toReturn = [hugeObj] { ...operate on hugeObj via shared_ptr... };
   (*hugeObj)[0] = HugeObject(...); // can alter lambda's behavior
   return toReturn;
}

I need a sort of “capture-by-move”, so:

  1. I create the vector
  2. I “inject” it in the lambda (treating the vector like a temporary)
  3. (outside) the vector will be in a “valid but unspecified state” (what standard says about moved objects)
  4. nothing from the outside can alter the lambda’s vector

Since we are on the subject, getting rid of shared_ptr syntax (I repeat: here) should be nice!

To emulate a move capturing we can employ a wrapper that:

  • receives an rvalue reference to our to-move object
  • maintains this object
  • when copied, performs a move operation of the internal object

Here is a possible implementation:

#ifndef _MOVE_ON_COPY_
#define _MOVE_ON_COPY_

template<typename T>
struct move_on_copy
{
   move_on_copy(T&& aValue) : value(move(aValue)) {}
   move_on_copy(const move_on_copy& other) : value(move(other.value)) {}

   mutable T value;

private:

   move_on_copy& operator=(move_on_copy&& aValue) = delete; // not needed here
   move_on_copy& operator=(const move_on_copy& aValue) = delete; // not needed here

};

template<typename T>
move_on_copy<T> make_move_on_copy(T&& aValue)
{
   return move_on_copy<T>(move(aValue));
}
#endif // _MOVE_ON_COPY_

In this first version we use the wrapper this way:

vector<HugeObject> hugeObj;
// ...
auto moved = make_move_on_copy(move(hugeObj));
auto toExec = [moved] { ...operate on moved.value... };
// hugeObj here is in a "valid but unspecified state"

The move_on_copy wrapper works but it is not completed yet. To refine it, a couple of comments are needed. The first is about “usability“: the only aim of this class is to “replace” the capture-by-copy with the capture-by-move, nothing else. Now, the capture by move makes sense only when we operate on rvalues and movable objects, so is the following code conceptually correct?

// due to universal referencing, T is const T&, so no copy/move will be involved in move_on_copy's ctor
const vector<HugeObject> hugeObj;
auto moved = make_move_on_copy(hugeObj);
auto toExec = [moved] { ...operate on moved.value... };
// hugeObj here is the same as before

Not only is it useless, but also confusing. So, let’s impose our users to pass only rvalues:

template<typename T>
auto make_move_on_copy(T&& aValue)
     -> typename enable_if<is_rvalue_reference<decltype(aValue)>::value, move_on_copy<T>>::type
{
   return move_on_copy<T>(move(aValue));
}

We “enable” this function only if aValue is an rvalue reference, to do this we make use of a couple of type traits. Strangely this code does not compile on Visual Studio 2010, so, if you use it, try to settle for:

template<typename T>
move_on_copy<T> make_move_on_copy(T&& aValue)
{
   static_assert(is_rvalue_reference<decltype(aValue)>::value, "parameter should be an rvalue");
   return move_on_copy<T>(move(aValue));
}

You can also enforce the requirement about move-constructability by using other traits such as is_move_constructible, here I have not implemented it.

The second note is about compliance. Is the following code syntactically-clear?

vector<HugeObject> hugeObj;
auto moved = make_move_on_copy(move(hugeObj));
auto toExec = [moved]
  {
     moved.value[0] = HugeObject(...); // is it conform to standard lambda syntax?
  };

What aroused my suspicions was the syntax of lambda expressions: if you copy-capture an object, the only way to access its non-const members (aka: make changes) is to declare the lambda mutable. This is because a function object should produce the same result every time it is called. If we want to support this requirement then we have to make a little change:

template<typename T>
struct move_on_copy
{
   move_on_copy(T&& aValue) : value(move(aValue)) {}
   move_on_copy(const move_on_copy& other) : value(move(other.value)) {}

   T& Value()
   {
      return value;
   }

   const T& Value() const
   {
      return value;
   }

private:
   mutable T value;
   move_on_copy& operator=(move_on_copy&& aValue) = delete; // not needed here
   move_on_copy& operator=(const move_on_copy& aValue) = delete; // not needed here
};

And:

vector<HugeObject> hugeObj;
auto moved = make_move_on_copy(move(hugeObj));
// auto toExec = [moved]  { moved.Value()[0] = HugeObject(...); }; // ERROR
auto toExec = [moved] () mutable { moved.Value()[0] = HugeObject(...); }; // OK
auto toExec = [moved]  { cout << moved.Value()[0] << endl; }; // OK

If you want to play a bit, I posted a trivial example on ideone.

Personally I’m doubtful if this is the best way to capture expensive-to-copy objects. What I mean is that working with rvalues masked by lvalues can be a little bit harder to understand and then maintaining the code can be painful. If the language supported a syntax like:

HugeObject obj;
auto lambda = [move(obj)] { ... };
// obj was moved, it is clear without need to look at its type

It would be simpler to understand that obj will be in an unspecified state after the lambda creation statement. Conversely, the move_on_copy wrapper requires the programmer looks at obj’s type (or name) to realize it was moved and some magic happened:

HugeObject obj;
auto moved_obj = make_move_on_copy(move(obj)); // this name helps but it is not enough
auto lambda = [moved_obj] { ... };
// obj was moved, but you have to read at least two lines to realize it

[Edit]

As Dan Haffey pointed out (thanks for this) “the move_on_copy wrapper introduces another problem: The resulting lambda objects have the same weakness as auto_ptr. They’re still copyable, even though the copy has move semantics. So you’re in for trouble if you subsequently pass the lambda by value”. So, as I said just before, you have to be aware some magic happens under the hood. In my specific case, the move_on_copy_wrapper works well because I don’t copy the resulting lambda object.

Another important issue is: what semantics do we expect when a function that performed a capture-by-move gets copied? If you used the capture-by-move then it’s presumable you didn’t want to pay a copy, then why copying functions? The copy should be forbidden by design, so you can employ the approach suggested by jrb, but I think the best solution would be having the support of the language. Maybe in a next standard?

Since other approaches have been proposed, I’d like to share with you my final note about this topic. I propose a sort of recipe/idiom (I think) easy to use in existent codebases. My idea is to use my move_on_copy only with a new function wrapper that I called mfunction (movable function). Differently from other posts I read, I suggest to avoid rewriting a totally new type (that may break your codebase) but instead inherit from std::function. From a OO standpoint this is not perfectly consistent because I’m going to violate (a bit) the is-a principleIn fact, my new type will be non-copyable (differently from std::function).

Anyhow, my implementation is quite simple:

template<typename T>
struct mfunction;

template<class ReturnType, typename... ParamType>
struct mfunction<ReturnType(ParamType...)> : public std::function<ReturnType(ParamType...)>
{
  typedef std::function<ReturnType(ParamType...)> FnType;

  mfunction() : FnType()
  {}

  template<typename T>
  explicit mfunction(T&& fn) : FnType(std::forward<T>(fn))
  {}

  mfunction(mfunction&& other) : FnType(move(static_cast<FnType&&>(other)))
  {}

  mfunction& operator=(mfunction&& other)
  {
    FnType::operator=(move(static_cast<FnType&&>(other)));
    return *this;
  }

  mfunction(const mfunction&) = delete;
  mfunction& operator=(const mfunction&) = delete;
};

In my opinion, inheriting from std::function avoids reinventing the wheel and allows you to use mfunction where a std::function& is needed. My code is on ideone, as usual.

[/Edit]

Make the choice you like the most don’t forgetting readability and comprehensibility. Sometimes a shared_ptr suffices, even if it’s maybe untimely.

Lambdas are cool and it’s easy to start working with. They are very useful in a plenty of contexts, from  STL algorithms to concurrency stuff. When capturing by reference is not possible and capturing by copy is not feasible, you can then consider this “capture by move” idea and remember the language always offers the chance to bypass its shortcomings.

For an accountant, programming productivity can be defined as lines of clean, simple, correct, well-documented code per day. Actually, searching the web you can find a bunch of good/bad definitions but, as for the majority of my posts, here I’m going to refer to my real experience, being as much pragmatic as I can, then I’m not very interested in analysing all the possible definitions.

I like thinking as an engineer and for me productivity is a measure of the efficiency of production. Following this short post, we can say productivity is the value of code produced divided by the time spent to write it:

Productivity = Value / Time

So, there are two ways of increasing productivity:

  • Increase the value
  • Decrease the time spent to obtain it

The first point is non-trivial and can lead to an extremely long, full-of-abstract-conclusions discussion. What is value for a programmer? It’s not easy to say. You can read articles and books, work and code a lot but you probably won’t get a sole answer. In this post I’m going to deal with the second issue, giving you some practical examples about saving coding time and, as the title suggests, I’ll consider a specific technology that is C++ on Visual Studio (both 2010 and 2012).

One of the most common rumors about C++ is about poor productivity. I’ve heard tons of people saying that a C++ developer can’t be as fast as a C# or Java one, and that refactoring tools are quite helpless. I think this is true to all appearances, if one doesn’t go beyond its IDE or editor. I think productivity is about discipline. From reducing the mouse usage and applying loads of shortcuts, to studying/elaborating practices to be faster (not only about pure coding).

The first simple thing you can do is to use keyboard as much as possible and further. Why using three clicks when a combination of two keys suffices? Consider a trivial example: setting the start-up project in a solution. Suppose we have a huge solution with about a hundred projects, with some executables (the main program and several test projects). Why do we have to:

  • found the project to run (t1)
  • right-click on it (t2)
  • locate the “Set as a start-up project” menu item (t3)
  • click (t4)

when we rather could:

  • found the project to run (ts1)
  • left-click on it (ts2)
  • press ALT+S+S (ts3)

t1 and ts1 (“s” stands for “shortcut”) are equal, the same applies to t2 and ts2, but ts3 is dramatically faster that t3 (+ t4) because it requires no mental effort, no reading time and no mouse-movement-and-click. You just have to remember a shortcut and this will be a kind of automatic gesture if you do it a couple of times.

I’m sure you already use shortcuts, anyhow setting them in Visual Studio is a trifle: just click on Tools, then Options and then Keyboard in the Environment section, as follows:

Another shortcut I can’t live without regards the pending changes tab and the compare with latest version feature. (if you use TFS, you know them). Basically I press:

  • CTRL+ALT+Home to show the Pending changes tab
  • I move among pending files with Up and Down keys
  • I press CTRL+ALT+PageUp to enter in the compare-with-latest-version mode

This way I don’t need to take my hands off the keyboard, being faster (thanks Gigi for this!).

Other shortcuts you shouldn’t miss are about compilation, such as solution building, project building, compile single file (Visual Studio should have them by default). They are helpful because, when adding or changing things, it is generally good to do sort of incremental compilation, maybe starting from a single file (if it is new) and then building the entire solution (or project, if the changes are very localized). Other related tips (or practices, if you prefer) such as “run all tests” and “make incremental check-ins” can help a lot your productivity but they are part of another story.

So, shortcuts are valuable allies, aren’t they? Practice. Customize your environment. What kind of actions can you perform faster by using shortcuts? Comprehend and, eventually, change your development process.

Ok, these themes are universal and they always apply, regardless of language and editor/IDE. Now, I’ll spend some words on a specific Visual Studio extension that can help your productivity: Visual Assist X. A standard license costs less than 300$ and I think it’s worth having a copy.

This tool not only has some standard refactoring features such as Extract method and Create from usage, but also C++ specific aids such as Add include. It goes without saying that you might (and should) bind each action to a custom shortcut. I’ve measured I’ve been significantly faster since I’ve started making use of Visual Assist X. That’s because it lets you focus on coding rather than some non-core aspects such as what file must be included (even if sometimes it’s worth including by hand for advanced stuff) or declaring a member-function in the header file while you’re writing it in the cpp file. It’s cool.

Other Visual Assist’s gems are some how-is-it-possible-visual-studio-does-not-have-them, like:

  • quick find references – find usages of functions and classes (Shift+ALT+F by default)
  • quick open file in solution (Shift+ALT+O by default)
  • quick find symbols (Shift+ALT+S by default)
  • quick swith between header and source (ALT+O by default)
  • quick methods listing (ALT+M by default)

Convince your boss to buy it!

Last (but not least) pearl is about snippets (that are very common in this kind of tools – for example in Resharper for C# development) that is heavily useful (in C++ as well as in other languages). A snippet is just a shortcut that triggers a text (parameterizable) replacement.

For instance, on my configuration, if you write:

once and then you press TAB you’ll get:

#pragma once

With this simple snippet (triggered by cout followed by TAB):

cout << $end$ << endl;

You’ll  generate:

cout << -->cursorHere<-- << endl;

More complicated:

lam then TAB:

[$capture$] ($params$) { $end$ }

and a small dialog will appear asking for $capture$ and $params$ (possibly empty) and then creates a lambda expression replacing $capture$ and $params$:

And you’ll get:

[&takeThisByRef, aValue]() { -->cursorHere<-- }

Have fun with snippets and, as usual, create those you (really) need.

In this post I showed some simple tricks to increase your productivity coding in C++ on Visual Studio. These are futile if you don’t discipline yourself, if you don’t practice and if you don’t explore your IDE and its possibile extensions/plugins. For example, some people don’t know the possibility to vertical-select text in Visual Studio:

Do you?

Sometimes we want some code to be executed after (or just before) the end of a function, also if an exeception is thrown. Suppose to deal with a C API that requires an initialization call and a termination call, something like that:


void use_C_api()

{

   Init_Lib();

   code_that_could_throw();

   Terminate_Lib();

}

The first thing a C++ programmer could think about is to encapsulate the library usage in a wrapper and use RAII (Resource Acquisition is Initialization). For example:

class LibWrapper
{
public:
 LibWrapper()
 {
    Init_Lib();
 }

 ~LibWrapper()
 {
    Terminate_Lib();
 }

 Call_code_that_could_throw()
 {
    code_that_could_throw();
 }
};

...

void use_C_api()
{
   LibWrapper wrapper; // Init here
   wrapper.Call_code_that_could_throw();
} // Terminate here (also if an exception occurs)

In C++  the only code that can be guaranteed to be executed after an exception is thrown are the destructors of objects residing on the stack, so this is our case.

Ok cool, but what if we just want to execute some code in a function? Do we have to write classes? What if we need something like Java’s finally or Go’s defer? Sometimes this kind of constructs suffice.

RAII is perfect for our purpose, but we need to create on-the-fly a sort of “finalizer”, passing it some code. Thanks to C++11 we can use lambdas to be enough generic. So, this is my idea:

template <typename F>
struct finalizer
{
template<typename T>
finalizer(T&& f) : m_f(std::forward<T>(f)) {}

~finalizer()
{
   m_f();
}
private:
   F m_f;
};

template <typename F>
finalizer<F> defer(F&& f)
{
   return finalizer<F>(std::forward<F>(f));
}

...

auto atEnd = defer( []{cout << "I'm printed out at the end of the scope!" << endl;} );

The code is trivial: the finalizer uses a template to accept any kind of “executable object” (lambdas, functions, functors, etc). I created a simple factory method to avoid expliciting the template parameter (the compiler will do the work for us).

But wait…I spot at least a possible problem in this mechanism, do you?

We’re relying on our compiler, aren’t we? What happens if our compiler doesn’t use RVO (Return Value Optimization)? We’ll be in a proper jam! We get a copy and then two destructions that lead us to a couple of calls to our at-end-code!

Is it clear? If not, try to change the factory this way and you’ll get the same effect:


template <typename F>
finalizer<F> defer_ops(F&& f)
{
   auto f1 = finalizer<F>(std::forward<F>(f));
   return f1;
}

Now our code is called twice (first when the copied object is destroyed, second at the end of the calling code’s scope). A simple way to “fix” this problem is to add a move constructor and a bool flag:

template <typename F>
struct finalizer
{
template<typename T>
finalizer(T&& f) : m_f(std::forward<T>(f)), m_isMoved(false) {}
finalizer(finalizer&& other) : m_f(std::move(other.m_f)), m_isMoved(other.m_isMoved)
{
   other.m_isMoved = true; // sort of "resource stealing" here
}
~finalizer()
{
  if (!m_isMoved)
  {
    m_f();
  }
}
private:
 F m_f;
 bool m_isMoved;
};

I don’t like this fix but it’s not possible to copy-assign a lambda-expression to another one (e.g. a no-op one – the idea would be to “reset” the moved finalizer’s m_f to an “empty” lambda). In fact the standard says “The closure type associated with a lambda-expression has a deleted copy assignment operator“.

If you’re unlucky and you compiler does not support C++11 move semantics then change your compiler! Obviously I’m joking. Let’s make another (even uglier) extra:

template <typename F>
struct finalizer
{
  // Please change it to a ctor taking a universal reference as soon as possible (when C++11 is available)
  finalizer(F f) : m_f(f), m_isMoved(false) {}

  // Please change it to a move ctor as soon as possible (when C++11 is available)
  finalizer(const finalizer& other) : m_f(other.m_f), m_isMoved(false)
  {
     other.m_isMoved = true; // sort of "resource stealing" here
  }
  ~finalizer()
  {
    if (!m_isMoved)
    {
      m_f();
    }
  }
  private:
   F m_f;
   // Please remove this mutable as soon as possible (when C++11 is available)
   mutable bool m_isMoved;
};

The key here is to replace the move constructor with the copy constructor and to add the mutable qualifier to our m_isMoved flag. Why? To be standard (the standard copy constructor receives a const&) and clear (it’s a design choice, though it is nasty).

To sum up: we started from a sort of elegant and simple code and we sank into a worse patched one. This regression may be caused by compilers that poorly support modern C++. In five minutes we wrote a simple code that worked and that solved our problem. More time was spent to fix and to meet compiler’s deficiencies.

RVO is a stupid example because I think that almost all C++ compilers support it, but sometimes you maybe need to disable it for some reason. Your code has to be prepared and must keep on working. Then be aware that design decisions are often made not only because of “core-business” but also because of your tools and facilities that are also part of your priorities just because they support your production. The more bad decisions are made because of infrastructure, the more you’re probably in trouble!

So, don’t forget to keep the barrel clean!

[Edit] Thanks to tr3w for letting me know some typos [/Edit]

The QTestLib framework is a tool for unit testing Qt based applications and libraries. I find it precious and simple to use, though it lacks some important features, supported, for example, by GTest. I’m not talking about mocking – for this you generally need an out-and-out framework (like GMock) – instead, I’m referring to simple things like fast deploying. Suppose you have written a test class like this:

#ifndef WIDGETTEST_H
#define WIDGETTEST_H

#include <QObject>

class WidgetTest : public QObject
{
 Q_OBJECT
private slots:
 void My_first_test();
 void On_button_pressed_should_save_the_world();
};

#endif //WIDGETTEST_H

The simplest approach to run all tests is to call QTest::qExec in your main:

#include "WidgetTest.h"
int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
    WidgetTest wtest;
    return QTest::qExec(&wtest, argc, argv);
}

Now what if you add a new test class? This approach brings you about:

  • Adding a new test (ok, this is normal),
  • Including its header in main.cpp (bad),
  • Laying a hand on the code in main.cpp (super bad), maybe xor-ing all the results.

This can be a pain for your productivity – before, the term “deploying” was related to “up and running on continuous integration systems” (e.g. TeamCity).

So, the first thing is about this. How to provide a simple and fast way to add new test classes with minimal impact? I’d like to write support code once.

The approach I currently use is this:

  • I have a test runner that holds a list with all the test objects to run,
  • each test class includes this runner and uses a special macro to add itself to the list,
  • main.cpp includes the runner and uses another macro to run all tests.

Let me show you the code:

#ifndef TESTRUNNER_H
#define TESTRUNNER_H

// Qt includes
#include <QTest>
#include <QSharedPointer>
// std includes
#include <algorithm>
#include <list>
#include <iostream>

//////////////////////////////////////////////////////////////////////////
// Test Runner allows automatic execution of tests
class TestRunner
{
public:

static TestRunner& Instance()
{
   static TestRunner instance;
   return instance;
}

template <typename T>
char RegisterTest(char* name)
{
   if ( std::find_if( begin(m_tests), end(m_tests), [&name](QSharedPointer<QObject>& elem)
   { return elem->objectName() == name; }) == end(m_tests) )
    {
      QSharedPointer<QObject> test(new T());
      test->setObjectName(name);
      m_tests.push_back(test);
   }
   return char(1);
}

int RunAll(int argc, char *argv[])
{
   int errorCode = 0;
   std::for_each( begin(m_tests), end(m_tests), [&] (QSharedPointer<QObject>& test)
   {
      errorCode |= QTest::qExec(test.data(), argc, argv);
      std::cout << std::endl;
   } );

   return errorCode;
}

private:
   std::list<QSharedPointer<QObject>> m_tests;
};

// Use this macro after your test declaration
#define DECLARE_TEST(className)\
    static char test_##className = TestRunner::Instance().RegisterTest<className>(#className);

// Use this macro to execute all tests
#define RUN_ALL_TESTS(argc, argv)\
    TestRunner::Instance().RunAll(argc, argv);

#endif // TESTRUNNER_H

The trick is to define static variables (chars in this case) that will be constructed before the program starts (registering the tests to the runner). Instead of chars (that I know, it seems like a hack, it’s not a good design), we could use another object that handles the registration during its construction:

template <class T>
class TestAdder
{
public:
 TestAdder(const QString& name)
 {
   auto newTest = new T();
   newTest->setObjectName(name);
   TestRunner::Instance().RegisterTest(newTest);
 }
};

TestRunner defines a simpler function:

void RegisterTest(QObject* test)
{
   auto testName = test->objectName();

   if ( std::find_if(begin(m_tests), end(m_tests), [&testName](QSharedPointer<QObject>& elem)
        { return elem->objectName() == testName; }) == end(m_tests) )
       m_tests.push_back(QSharedPointer<QObject>(test));
}

And the macro turns into the cleaner:

#define DECLARE_TEST(className) static TestAdder<className> t(#className);

By the way, here is how our widget test looks like:

--- WidgetTest.h" ---
#ifndef WIDGETTEST_H
#define WIDGETTEST_H

#include "TestRunner.h"
// Qt includes
#include <QObject>

class WidgetTest : public QObject
{
 Q_OBJECT
private slots:
 void My_first_test();
 void On_button_pressed_should_save_the_world();
};

DECLARE_TEST(WidgetTest)
#endif //WIDGETTEST_H

--- WidgetTest.cpp ---
#include "WidgetTest.h"

void WidgetTest::My_first_test()
{
  ...
}

void WidgetTest::On_button_pressed_should_save_the_world()
{
   ... important test :)  ...
}

And main.cpp is straightforward:

#include "TestRunner.h"
int main(int argc, char *argv[])
{
    QApplication app(argc, argv);
    return RUN_ALL_TESTS(argc, argv);
}

It’s simple, isn’t it? Now you can add tests easily. Disabling a test? Create an “empty” macro like DECLARE_TEST_DISABLED(className) that does nothing, or just comment the line DECLARE_TEST(className).

The second issue I’m dealing with is about test fixtures: what if you find yourself writing two or more tests that operate on similar data? For example, GTest allows you to reuse the same configuration of objects for several different tests. It is damned shrewd about this and it uses inheritance to make each test function have its own copy of the data. I heartily recommend you to dive into the internals!

Here I’d like to keep on exploiting QTest’s running mechanism (e.g. automatic execution of all the private slots of a test class), maybe adding some tricks to increase our productivity. So, we know QTest treats four slots in a special way:

  • initTestCase() will be called before the first testfunction is executed,
  • cleanupTestCase() will be called after the last testfunction was executed,
  • init() will be called before each testfunction is executed,
  • cleanup() will be called after every testfunction,

Quick recap, we have:

#ifndef WIDGETTEST_H
#define WIDGETTEST_H

#include "TestRunner.h"
// Qt includes
#include <QObject>

class WidgetTest : public QObject
{
 Q_OBJECT
private slots:
 void My_first_test();
 void On_button_pressed_should_save_the_world();
private:
 SomeData m_data;
};

DECLARE_TEST(WidgetTest)
#endif //WIDGETTEST_H

And we want m_data to be fresh and renewed before each test function gets executed. In a first attempt we could renew m_data in the init slot – that will be called before each testfunction is executed. Ok this sounds good, but what if SomeData is noncopyable/nonassignable (like QObject is)? A possible solution employs pointers – actually I use a smart pointer to avoid deleting the object by hand:

#ifndef WIDGETTEST_H
#define WIDGETTEST_H

#include "TestRunner.h"
// Qt includes
#include <QObject>
// std includes
#include <memory>

class WidgetTest : public QObject
{
 Q_OBJECT
private slots:
 void init();
 void My_first_test();
 void On_button_pressed_should_save_the_world();
private:
 std::unique_ptr<SomeData> m_data;
};

DECLARE_TEST(WidgetTest)
#endif //WIDGETTEST_H

--- WidgetTest.cpp ---

...

void WidgetTest::init()
{
   m_data.reset( new SomeData(aParameter) );
}

Thus, every time a test function is executed, it will have a “new” m_data. This way you can pretend that QTest has fixtures! Another valuable thing you should reckon in is about inheritance: suppose you have a couple of tests that only use common (not shared!) data (say a couple of widgets initialized in a certain way). You can extract this aspect in a class – such as “SpecialWidgetTestBase” – and make your tests inherit from it:

...

class SpecialWidgetTestBase : public QObject
{
   Q_OBJECT
private slots:
   void init(); // reset the unique_ptrs
protected:
   std::unique_ptr<QWidget> m_specialWidget;
   std::unique_ptr<QTextEdit> m_specialTextEdit;
};

...

class GUIPerformanceTest : public SpecialWidgetTestBase
{
   Q_OBJECT
private slots:
   void On_image_load_benchmark();
   void When_mouse_move_benchmark();
};
DECLARE_TEST(GUIPerformanceTest)

...

class GUIActionsTest : public SpecialWidgetTestBase
{
...
};
DECLARE_TEST(GUIActionsTest)

Both your tests will have base class’ protected data resetted before each test function runs! But if a subclass (say GUIActionTest) had redefined the init slot, the parent class’ one would not have been executed – init is not “recursive”. In this case:

  • make the init() function in the base class a public slot,
  • call it from the init() of the derived class,
  • make other stuff in the init() of the derived class (e.g. other resetting)

The last thing I’m going to handle is very trivial, but often can make your work faster: output. I want QTest to color its results. A nasty red line if a test fails, a gentle green one if a test passes. So, please, it’s your productive programmer speaking: make your output colored, I don’t care how, a stupid post-processing executable suffices:

MyProgram.Tests.exe | MakeMyEyesightHappy.exe

And you can peacefully configure your IDE (or editor) to execute a custom command. For example, under Windows, the stupid program can be easier (and terribly better) than this:

#include <windows.h>
#include <iostream>
#include <string>
#include <regex>

enum Color { blue=1, green, cyan, red, purple, yellow, grey, dgrey, hblue, hgreen, hcyan, hred, hpurple, hyellow, hwhite };

using namespace std;

void SetConsoleColor( Color color )
{
   SetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE), (WORD) color);
}
WORD GetConsoleColor ()
{
   auto consoleHandle = GetStdHandle(STD_OUTPUT_HANDLE);
   CONSOLE_SCREEN_BUFFER_INFO con_info;
   GetConsoleScreenBufferInfo(consoleHandle, &con_info);
   return con_info.wAttributes;
}

class ColorGuard
{
public:
 ColorGuard() : m_color(GetConsoleColor())
 {}

 ~ColorGuard()
 {
    SetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE), m_color);
 }

private:
 WORD m_color;
};

int main()
{
  string line;

  regex fail("(FAIL.*)");
  regex pass("(PASS.*)");

  while (getline(cin, line))
  {
    ColorGuard guard;

    if (regex_match(line, fail))
    {
      SetConsoleColor(hred);
    }

    if (regex_match(line, pass))
    {
      SetConsoleColor(hgreen);
    }

    cout << line << endl;
  }

  return 0;
}

And you’ll finally have a colored report! Don’t forget to take care of your output: you can also customize the TestRunner seen before making advanced stuff – for example filtering (QTest already provides some filtering, see here).

Then, you know how to improve your QTest process and productivity. Use a test runner, you’ll focus only on tests and you won’t be distracted from deploying them. If you need test fixtures, use pointers (better if smart!) and identify abstractions if some test classes have common data. At last (but not least), don’t ignore the output: the more it is evident, the more fast and productive you become!

Since C++11, std namespace includes a generalization of pair: tuple, that is a heterogeneous fixed-size collection of values – std::tuple is  the standardization of the boost tuple library. Tuples are convenient in exactly what you expect: packing types. A couple of examples are: making it easy to define functions that return more than one value and emulating variadics – if your compiler does not support them.

In this post I’m going to discuss another worthwhile usage of tuples that I call multi-type dispatching.

Recalling my previous post about policies, I showed a simple logger class with two policies: filtering and outputting. Filtering was based on function template specializations, something like this:


struct ErrorFilter
{
     // pass nothing by default
     template<typename Severity>
     bool Filter() { return false; }
};

// Specialization -> Let pass errors
template<>
bool ErrorFilter::Filter<Error>() { return true; }

I promised another approach, with no specializations. This is based on tuples as well as a bit of metaprogramming. The idea pertains to a general concept. Suppose I have a function:

template <typename T>;
void function()
{
    ... something ...
}

and suppose I want to specialize it not only for T=int but also for T=float and T=double, and I want to provide the same implementation to all of them. Probably the simplest solution is forwarding:

template <>
void function<int>()
{
    ... something ...
}

template <>
void function<double>()
{
    function<int>(); // forward
}

template <>
void function<float>()
{
    function<int>(); // forward
}

This solution leads to code duplication. And what if we have:

template <typename T>
void function(T t)
{
    ... something ...
}

If we use forwarding then we have troubles with types:

template <>
void function<int>(int i)
{
    ... something ...
}

template <>
void function<double>(double d)
{
    function<int>(d); // forward to int??
}

template <>
void function<float>(float f)
{
    function<int>(f); // forward to int??
}

This solution seems not to be good. I would like an illegal code like this:

// illegal
template <typename T>
void function<int | float | double>(T t)
{
    ... called with either T=int, float or double ...
}

A filter could be an illegal class like this:

// illegal
class MultiFilter
{
    template<typename T>
    bool Filter() { return false; }

    template <>
    bool Filter<Error | Info>() { return true; }
}

To code a legal solution we can employ tuples. We use a tuple to pack types we want to “specialize togheter”, then we dispatch the input type T depending on its presence in that tuple. The bad news is that std::tuple does not have an “exists” member-function (nor a not-member function), the good news is that implementing that metafunction – a metafunction is either a class template (all of whose parameters are types) or a class with a publicly accessible nested result type (or const value) – is easy. Let’s start with it:

// needed for is_same
#include <type_traits>
#include <tuple>

using namespace std;

// this should be an inner and private metafunction of exists_type
// I put here for clarity
template<typename T, typename Tuple, const int index>
struct exists_type_index
{
    static const bool value =
        is_same < T, typename tuple_element<index, Tuple>::type >::value ||
                  exists_type_index<T, Tuple, index-1>::value;
};

// stop the recursion when reach the first element
template<typename T, typename Tuple>
struct exists_type_index<T, Tuple, 0>
{
    static const bool value = is_same < T, typename tuple_element<0, Tuple>::type >::value;
};

// exists_type metafunction (clients call this)
template<typename T, typename Tuple>
struct exists_type
{
    static const bool value = exists_type_index<T, Tuple, tuple_size<Tuple>::value-1>::value;
};

exists_type<T, Tuple> checks if an element of the same type of T exists in Tuple. It uses a support metafunction (exists_type_index) that does the work recursively: if the current type is the same as T then the bool value is true, otherwise the recursion goes on. When the current index is 0, the recursion stops. I borrowed these from the standard:

  • tuple_size<Tuple> to get the number of elements in Tuple,
  • tuple_element<N, Tuple> to get the N-th type in Tuple,
  • is_same to check if two types are the same.

Note that the job is performed at compile time. We can use exists_type this way:

tuple<int, float, string> tt;

exists_type<float, decltype(tt)>::value;  // 1
exists_type<double, decltype(tt)>::value; // 0
exists_type<string, decltype(tt)>::value; // 1

Now we can employ this utlity for dispatching. Take a deep breath here:

template<bool b>
struct Executor
{
 template<typename T>
 static void execute(T&&)
 {
    cout << "General case" << endl;
 }
};

template<>
struct Executor <true>
{
 template<typename T>
 static void execute(T&&)
 {
    cout << "Specific case" << endl;
 }
};

// clients call this
template<typename Tuple>
struct MultiTypeDispatcher
{
 template<typename T>
 void function( T&& t )
 {
      Executor<exists_type<T, Tuple>::value>::execute(forward<T>(t));
 }
};

// client code:
MultiTypeDispatcher< tuple<int, float, string> > dispatcher;

dispatcher.function(string("hello!")); // Specific case!
dispatcher.function(1.0f); // Specific case!
dispatcher.function(1.0); // General case!

I introduced the proverbial level of indirection and a bit of metaprogramming: the MultiTypeDispatcher uses the correct version of Executor depending on the compile-time-obtained boolean value. Using the example above: string is in the tuple, so the MultiTypeDispatcher will use Executor<true>; conversely, 1.0 is a double that is not in the tuple so Executor<false> (general case) will be used.

This approach carries several advantages:

  • no code duplication
  • which version of Executor::execute will be called is deduced at compile-time
  • flexibility (just change tuple’s contents)
  • function’s parameter type is not lost

Our logger example is a very special case because it does not need an executor at all:

template<typename Tuple>
struct MultiFilter
{
   template<typename T>
   bool Filter()
   {
       // just a check will suffice
       // (because the filtering has a trivial logic)
       return exists_type<T, Tuple>::value;
   }
};

// client code

typedef MultiFilter< tuple<Error, Info> > MyFilter;

SillyLogger<MyFilter, OStreamPolicy> logger(cout);

logger.Log<Generic>("Not Logged");
logger.Log<Info>(string("Logged!"));
logger.Log<Error>(1.0);

Another little suggestion: instead of using a bool as Executor’s template parameter, use an int. The reason is for extensibility: it doesn’t hurt to use an int, and doing so allows additional alternative implementations to be added easily in the future as needed (suppose your dispatcher will use more than one tuple or another trickier logic).

We can finally obtain a similar effect of the illegal code I wrote before. This approach can be also useful when you need to generate the same implementation to several functions that accept only certain types. The sole difference with the Dispatcher-Executor machinery is that the primary template of Executor does not define its member-function execute:

template<int i>
struct Executor
{}; // empty

template<>
struct Executor <1>
{
 // defined only here
 template<typename T>
 static void execute(T&&)
 {
    cout << "Specific case" << endl;
 }
};

// client code
MultiTypeDispatcher< tuple<int, float, string> > dispatcher;

dispatcher.function(string("hello")); // Specific case!
dispatcher.function(1.0f); // Specific case!
dispatcher.function(1.0); // ops, compile-time error!

The last line tried to call Executor<0>::execute that does not exist! It’s simple, isn’t it?!

This code is here.

To conclude, tuples are important for grouping types (and values) as well as for metaprogramming jobs (like typelists, but typelists do not contain values); the standard provides all the basic bricks to operate on them – e.g. tuple traversal can be performed at compile-time – and building more complex components is feasible (e.g. exists_type). Never underestimate their potential!

[Edit]

When I wrote this post it was longer and more complicated than now. Thanks to Davide Di Gennaro for showing me that this approach was simpler than I thought!

[/Edit]

The curiously recurring template pattern (CRTP) is a C++ idiom in which a class X derives from a class template instantiation using X itself as template argument [Wikipedia]. Its general form is pretty easy:

template <typename T>
struct Base
{
    // ...
};

struct Derived : Base<Derived>
{
    // ...
};

Typically, this pattern is used for static polymorphism (aka, simulated dynamic binding) as well as code injectio: inside Base’s methods you can take advantage of the fact that T derives from Base, then you can static_cast the this pointer to T*:

template <typename T>
struct Base
{
    void interface()
    {
        // ...
        static_cast<T*>(this)->implementation();
        // ...
    }
};

struct Derived : Base<Derived>
{
    void implementation();
};

This short post is not about CRTP in general – for this read, for example, Wikipedia - here I’ll show how to use this pattern for polymorphic method chaining. Briefly: each method returns an object (possibly the current object itself), allowing the calls to be chained together in a single statement (a typical use – the named-parameter idiom – here “Learn how to support named parameters in C++“).

Suppose you have to write a trivial printer class looking like this:

class Printer
{
public:
      Printer(ostream& pstream) : m_stream(pstream) {}

      template <typename T>
      void print(T&& t) { m_stream << t; }

      template <typename T>
      void println(T&& t) { m_stream << t << endl; }
private:
      ostream& m_stream;
};

I’m used to be lazy and I get tired writing code like this (suppose I may not use the operator<<):

Printer printer(cout);
printer.print("Message");
printer.print(105);
printer.println(objectHavingOutOperator);

So I change a couple of things in the Printer class:

class Printer
{
public:
      Printer(ostream& pstream) : m_stream(pstream) {}

      template <typename T>
      Printer& print(T&& t) { m_stream << t; return *this; }

      template <typename T>
      Printer& println(T&& t) { m_stream << t << endl; return *this; }
private:
      ostream& m_stream;
};

Then we write:

Printer(cout).print("Message").print(105).println(objectHavingOutOperator);

Ok, that’s good but what if I create some classes deriving from Printer? Chaining is lost, isn’t it? That’s because the return type of both print and println is Printer&, ever.

A simple way to maintain the chain consists in using CRTP:

template <typename ConcretePrinter>
class Printer
{
public:
      Printer(ostream& pstream) : m_stream(pstream) {}

      template <typename T>
      ConcretePrinter& print(T&& t)
      {
          m_stream << t;
          return static_cast<ConcretePrinter&>(*this);
      }

      template <typename T>
      ConcretePrinter& println(T&& t)
      {
          m_stream << t << endl;
          return static_cast<ConcretePrinter&>(*this);
      }
private:
      ostream& m_stream;
};

class CoutPrinter : public Printer<CoutPrinter>
{
public:
     CoutPrinter() : Printer(cout) {}

     CoutPrinter& SetConsoleColor(Color c) { ... return *this; }
};

... client code ...

CoutPrinter().print("Hello ").SetConsoleColor(Color.red).println("Printer!");

This approach does not allow using a Printer class directly (sans a deriving class, due to CRTP). To evade this requirement, I suggest you to provide another base printer, like this:

class BasePrinter : public Printer<BasePrinter>
{
public:
    BasePrinter(ostream& stream) : Printer(stream) {}
};

This way you can use the Printer directly:

BasePrinter(cout).print("Hello ").println("Printer");

In general, for a longer hierarchy:

// Base class
template <typename T>
struct Base
{
 T& BaseMethod()
 {
    return static_cast<T&>(*this);
 }
};

// Inherits from Base
template <typename T>
struct Child : public Base<T>
{
 T& ChildMethod()
 {
    return static_cast<T&>(*this);
 }
};

// Inherits from Child
template <typename T>
struct ChildChild : public Child<T>
{
 ChainingReturnType& ChildChildMethod()
 {
    return static_cast<T&>(*this);
 }
};

...

Chaining works at compile-time because it uses the static type of the objects involved.

What I don’t like is the number of classes we generate to use directly all the bases: we have to define an alter-ego for each of them – and introducing a new level of indirection could be verbose:

template<typename T>
struct Base
{
   Base(...suppose some parameters...) : ... {}

   //some methods
};

struct Base_User : public Base<Base_User>
{
   Base_User(...) //...must construct Base...
   // sort of duplicated code
};

template<typename T>
struct Derived : Base<T>
{
   Derived(...suppose some parameters...) //...must construct Base & itself...

   // other methods
};

struct Derived_User : public Derived<Derived_User>
{
   Derived_User(...) //...must construct Derived...
   // sort of duplicated code
};

If you want to avoid repeating code (e.g. construction) in _User classes you can employ the idea I showed in a previous version of this post: instead of deriving from Base, Base_User is just a typedef of Base using a special type (NoCRTP) as a template parameter. This type either “enables or disables” the usage of CRTP. The code can seem complicated but it’s simpler than you think:

// trivial type-selector

template<bool, typename T, typename U>
struct select_
{
   typedef T type;
};

template<typename T, typename U>
struct select_<false, T, U>
{
   typedef U type;
};

// just a placeholder
struct NoCrtp;

// support macro
#define CRTP_TYPE(who) typename select_ < is_same<T, NoCrtp>::value, who, T>::type

// another way to realize polymorphic chaining
template<typename T>
struct Base
{
   // if (T == NoCrtp)
   //   CrtpType = Base ("disable" CRTP)
   // else
   //   CrtpType = T ("enable" CRTP)
   typedef CRTP_TYPE(Base) CrtpType;

   CrtpType& chain()
   {
      //...
      return static_cast<CrtpType&>(*this);
   }
};

typedef Base<NoCrtp> Base_User; // no duplication

template<typename T>
struct Derived : public Base<CRTP_TYPE(Derived<T>)>
{
   typedef CRTP_TYPE(Derived) CrtpType;

   CrtpType& chain_derived()
   {
     //...
    return static_cast<CrtpTyep&>(*this);
   }
};

typedef Derived<NoCrtp> Derived_User; // no duplication

...

This machinery is a bit more complicated to understand but it can avoid duplication. Choose the implementation that fits your needs.

In summary: method chaining may be elegant and useful. Its power is damped if inheritance is involved so I suggest to employ CRTP, “champion of static polymorphism” which can support method chaining, avoiding you to write lots of code. If you have more than a couple of classes your codebase may be more verbose, but don’t be afraid of this idiom, it can be a valuable ally!

Designing software systems is hard because it constantly asks you to choose, and in program design, just as in life, choice is hard. Choices can be conbined, which confers on design an evil multiplicity. Writing generic code is about giving the user the capability to choose the combination she likes the most and, possibly, the faculty to expand/customize the initial codebase.

C++ vector is a good example: it lets you choose what type of objects you are going to store in and, in case, what allocator you want to use. The allocator is optional because vector provides a default parameter. Default choices are prominent when your component admits simplified/general usage.

This post deals with fighting against evil multiplicity using a flexible and generative approach. I’m going to build a step-by-step example to support the discussion.

Consider a trivial logger class:

class Logger
{
public:
     Logger(ostream& stream) : m_stream(stream) {}

     void Log(const string& message)
     {
          m_stream << message;
     }

private:
     ostream& m_stream;
};

I have already made some decisions: construction (provide a reference to an ostream), message type (string), what to log (log everything), how to log (just use operator<<). Improving genericity by logging every type supporting operator<< is quite simple:

template <typename MessageType>
void Log(const MessageType& message)
{
     m_stream << message;
}

Templates come to the rescue. Now, what if we want to choose what to log? Suppose we want to filter log entries depending on a certain severity (e.g. info, error, debug). Log method could look like this:

template <typename MessageType>
void Log(const MessageType& message, const Severity& severity)
{
     if (...severity...)
          m_stream << message;
}

How to choose what to log here? An approach could be injection:

class Logger
{
public:
     Logger(ostream& stream, Filter& filter) : m_stream(stream), m_filter(filter) {}

     template <typename MessageType>
     void Log(const MessageType& message, const Severity& severity)
     {
          if (m_filter.CanPrint(severity))
               m_stream << message;
     }
private:
     ostream& m_stream;
     Filer& m_filter;
};

Consider an example of usage:

ErrorFilter filter;
Logger logger = Logger (cout, filter);
logger.Log("Hello, this is an info and won't be logged!", Info());
logger.Log("This error will be logged!", Error());

What I dont’ like:

  • Creating severities every time I have to log,
  • Creating a filter and worrying about its ownership,
  • Making static decisions and using them “dynamically”.

Consider the first issue. To avoid creating severity objects every time Log method is called, we can employ templates, again:

template <typename SeverityType, typename MessageType>
void Log(const MessageType& message)
{
if (m_filter.CanPrint<SeverityType>())
          m_stream << message;
}

I swapped SeverityType and MessageType to omit the second template parameter and let the compiler to get by on its own:

logger.Log<Error>("this is an error!");

Second and third issues are strictly related: first I created a filter then I injected it into the Logger. I consider these operations dynamic, meaning that the binding between Logger and Filter is after the program starts. How can we improve this? How can we benefit from static binding here?

An elagant way to encapsulate “static” decisions is built on policies. The mechanics of policies consist of a combination of templates with multiple inheritance. This technique is purposely conceived to support flexible code generation by combining a small number of these “primitive devices”. It’s easier to apply a filter policy to our example than to bore you with abstract concepts:

template <typename FilterPolicy>
class Logger : public FilterPolicy
{
     // just for readablity (a sort of "specification")
     using FilterPolicy::Filter;
public:
     Logger(ostream& stream) : m_stream(stream) {}

     template <typename SeverityType, typename MessageType>
     void Log(const MessageType& message)
     {
          // inherited from FilterPolicy
          if (Filter<SeverityType>())
               m_stream << message;
     }
private:
     ostream& m_stream;
};

A class that uses policies — a host class — is a template with many template parameters, each parameter being a policy. The host class “indirects” parts of its functionality through its policies and acts as a receptacle that combines several policies in a coherent aggregate.

Now we can use our Logger class easily:

// typedef Logger<ErrorFilter> LoggerErrorFilter; -> use typedef if you need readability
Logger<ErrorFilter> logger(cout);
logger.Log<Error>("this will be logged!");
logger.Log<Info>("this won't be logged!");

Possibile implementations of filter policies:

// Severity types
struct Info {};

struct Error {};

struct Generic {};

struct ErrorFilter
{
     // pass nothing by default
     template<typename Severity>
     bool Filter() { return false; }
};

// Specialization -> Let pass errors
template<>
bool ErrorFilter::Filter<Error>() { return true; }

Relying on template specializations you can quickly create new filters. Play – mildly – with macros if you are lazy:

// Generate a Filter by Name
#define CREATE_FILTER(Name)\
 struct Name \
 {\
 template<typename Severity> bool Filter() {return false;}\
 };

// [SUPPORT] Create a specialization
#define ADD_SEVERITY(FilterName, Severity)\
 template<> bool FilterName::Filter<Severity>() { return true; }

// One-Severity Filter
#define CREATE_FILTER_1(Name, Severity)\
 CREATE_FILTER(Name)\
 ADD_SEVERITY(Name, Severity)

// Two-Severities Filter
#define CREATE_FILTER_2(Name, Severity1, Severity2)\
 CREATE_FILTER_1(Name, Severity1)\
 ADD_SEVERITY(Name, Severity2)

// ... add 3,4,... versions if you need

// User's code

CREATE_FILTER_2(ErrorInfoFilter, Error, Info)

...

Logger<ErrorInfoFilter> logger(cout);
logger.Log<Error>("this will be logged!");
logger.Log<Info>("this will be logged too!");

This is just a possible implementation. In a future post I’ll show you another code based on tuples, with no macros nor specializations. By the way, you can add new filters with complicated logic by creating new policies that observe FilterPolicy’s specification (just the Filter function). Think of the specification as the methods the host class expects to use. This differs from classical object-orientation where you need to observe a typed interface; here this constraint is blunt because a policy only need to observe a sort of “signature expectations”.

Another responsability we can confine in a policy regards outputting the message:

struct OStreamPolicy
{
   OStreamPolicy(ostream& stream) : m_stream(stream) {}

   template<typename Message>
   void Out(const Message& message)
   {
       m_stream << message << endl;
   }

private:
   ostream& m_stream;
};

// very fake class!
struct DBPolicy
{
   DBPolicy(const string& credentials) : m_db(credentials) {}

   template<typename Message>
   void Out(const Message& message)
   {
       m_db.Insert(message);
   }

private:
   LogDB m_db;
};

template <typename FilterPolicy, typename OutPolicy>
class Logger : public FilterPolicy, public OutPolicy
{
     using FilterPolicy::Filter;
     using OutPolicy::Out;
public:
     template<typename ARG1>
     Logger(ARG1&& arg1) : OutPolicy(forward<ARG1>(arg1)) {}

     template <typename SeverityType, typename MessageType>
     void Log(const MessageType& message)
     {
          // inherited from FilterPolicy
          if (Filter<SeverityType>())
               // inherited from OutPolicy
               Out(message);
     }
};

...

Logger<ErrorFilter, OStreamPolicy> logger(cout);

Logger<ErrorFilter, DBPolicy> db_logger("POLICY-BASED");

I used perfect forwarding to enforce genericity. To improve this design you can, for example, employ a variadic constructor (generic and variable number of arguments). A radical approach could completely eliminate construction parameters:

struct CoutPolicy
{
   template<typename Message>
   void Out(const Message& message)
   {
      cout << message << endl;
   }
};

Choose the design more convenient for you but don’t be too maniac about static decisions (for example you may need to read a log file from a network source and this can’t be determined at compile time!). Adding other out policies is easier than adding filter ones!

The power of policies comes from their ability to mix and match. A policy-based class can accommodate very many behaviors by combining the simpler behaviors that its policies implement. This effectively makes policies a good weapon for fighting against the evil multiplicity of design.

Using policy classes, you can customize not only behavior but also structure. This important feature takes policy-based design beyond the simple type genericity that’s specific to container classes.

The last thing I’m going to show you is about enriched behavior: a policy can provide supplemental functionality that propagates through the host class due to public inheritance. Furthermore, the host class can implement enriched functionality that uses the optional functionality of a policy. If the optional functionality is not present, the host class still compiles successfully, provided the enriched functionality is not used.

For example, consider an OutPolicy such as:

struct SpecialOutPolicy
{
   template<typename Message>
   void Out(const Message& message)
   {
      // not relevant
   }

   template<typename Message>
   void SpecialOut(const Message& message)
   {
      // another logging method, not "required" by the host class "specification"
   }
};

You inherit SpecialOut by instantiating a Logger templetized on SpecialOutPolicy. This feature can be particularly useful when you need to control what operations can be executed according to static (aka by design) constraints. Trivial example: suppose you have to interact with an I/O device through a certain wrapper, specifying an appropriate opening mode (e.g. text read, text write, binary read, binary write). An old-style implementation could be:

class IODeviceWrapper
{
     IODeviceWrapper(int mode) // lots of #defines to avoid numbers
     { ...  }
     <SomeType> Read(<SomeParameters>) { ... }
     <SomeType> Write(<SomeParameters>) { ... }
     ...
};

What if I instantiate the device using a read mode and then I attempt to write? It shouldn’t be permitted by design. We can enforce this constraint by employing policies:

template<typename Mode>
class IODeviceWrapper : public Mode
{
   ...
};

struct ReadMode
{
    <SomeType> Read(<SomeParameters>) { ... }
};

struct WriteMode
{
    <SomeType> Write(<SomeParameters>) { ... }
};

struct ReadWriteMode : public ReadMode, public WriteMode {};

...

IODeviceWrapper<OpenMode> wrapper;
wrapper.Read(...); // ok
wrapper.Write(...); // not compile

IODeviceWrapper<ReadWriteMode> anotherWrapper;
anotherWrapper.Read(...); // ok
anotherWrapper.Write(...); // now ok

Such techinques can enforce not only customization but also design constraints. Thanks to their flexibility, policies are great allies if you are writing a library or a set of APIs. Furthermore, policy-based design is open-ended that is the library should expose the specifications from which these policies are built, so the client can build her own.

If you want to study in deep this topic I recommend Modern C++ Design by Alexandrescu. In addition to an excellent introduction to policy-based design, you can find real examples of usage applied to design patterns (e.g. command, visitor). Although this book was written more than 10 years ago, you can learn:

  • non-trivial examples of policy-based classes,
  • template metaprogramming techniques,
  • C++ & modern implementations of Design Patterns,
  • implementation ideas of some C++11 concepts.

Policy-based design requires you to change point of view about software decisions. Consider not only dynamic binding but also static (or compile time) binding. A more powerful approach lies in mixing static binding with dynamic binding, but this is another story!