One of the most interesting addition of C++11 is the move semantic. It enables an optimization which occurs in place of a copy when a given class supports it. In addition to this, when a class does not support moveability, the new semantic decays to a bare copy, so that the correctness of generic code is in any case not compromised.

Movability is enabled by the r-value reference. Declaring the move constructor and the move assignment operator for a given object is just enough to observe performance improvements in legacy codes (recompiled with a modern C++11 compiler). Only in few cases where l-value instances need to be moved, the additional use of the helper functions std::move is required.

While in real life the copy semantic is an abstract concept, the move semantic is very concrete one. An object can be moved from a point (a) to a point (b), by applying a force to it in accordance with the Newton’s Second Law. The provided work moves the object that is physically transfered to a different coordinate (the friction consumes the energy of the object, which, in turn comes to halt after a while the force is no longer applied). From the C++11 point of view, this concept is expressed by the following statement:

Object b = std::move(a);

while a and b a are different instance located at different memory addresses, the meaning of such a statement is that the instance of the object (a) is now moved to the address of (b) (technically the internals of the object (a) are moved into the new object (b), but these details are beyond the scope of this essay).

Although the object (a) is valid after the move, it is left in a state only suitable for destruction or re-assignment. From the perspective of the client code, the object has been logically moved. The C++11 standard require, indeed, that the value of the object (b) is equivalent from that of the object (a) prior the move.

That said, any raw pointer referring to (a) it is to be considered “invalid”, in that even if it refers to an object only supposed to be destroyed (or reassigned, as suggested by Julien).

std::vector vec;
Object * ptr = &a;
vec.push_back(std::move(a));
// from now on ptr is no longer logically usable...

As shown in this example, It would be desirable to have ptr referring to the object moved inside the vector. To enable this, the pointer should be smart enough to detect when the resource has been logically moved at a different address and to be able to update its internals accordingly. It’s not the case of raw pointers anyway.

The entangled_ptr<> class.

more::entangled_ptr is a novel smart pointer class that enables tracking semantic. It is different from std::shared_ptr, in that its primary aim is not to manage the ownership of the allocated resource. Instead, the entangled_ptr is supposed to track objects while they are moved around by means of the move semantic.

For an object, in order to be track-able by an entangled_ptr, its class type must derive from the more::enable_entangled_from_this<>, much like a class must derives from std::enable_shared_from_this<> to be able to generates shared_ptr<> pointing to its instances.

class Object : public more::enable_entangled_from_this<Object>

The Object class inherits the method entangled_from_this() which returns an entangled_ptr<> referring to the instance:

Object instance;
auto ptr = instance.entangled_from_this();

From now on it’s possible to move the object around; the entaglet ptr will be tracking it!

vec.push_back(std::move(instance));
ptr->method(); // it's still ok, the method is invoked on the instance moved into the vector.

Implementing a track-able and move-able object.

For an object to be track-able by an entangled_ptr, not only its class must derive from more::enable_entangled_from_this<>, but also it must be implementing the move constructor and the move assignment operator properly.

    struct test : public more::enable_entangled_from_this<test>
    {
        test() = default;

        test(test &&rhs)
        : super(std::move(rhs))
        {
            ...
        }

        test& operator=(test &&rhs)
        {
            super::operator=(std::move(rhs));
            ...
        }

It’s worth noting that the more::enable_entangled_from_this<> class type-defines itself as ‘super’ in order to relax the typing required to invoke the move constructor and the move assignment operator of the base class. It is important to know that that such a class is non copyable because it would otherwise break the auto-referenced pointer semantic of the entangled_ptr, that must point to one resource at time.

The copy constructor and the assignment operator of the base class enable_entangled_from_this are deleted and, in turn, the class deriving from it is non copyable. A track-able object can be referenced by any number of entangled_ptr, which are instead copyable, as well as moveable. When a resources is moved at a different address, all the entangled_ptr referencing to it are updated accordingly.

The complete implementation of the more::entangled_ptr is available here, along with a comprehensive test. Enjoy C++11, always. Nicola

PFQ is capable of capturing million packets per second running on a commodity Xeon processor, equipped with an Intel 82599 10G network adapter.

The graph shows how well PFQ scales with the number of cores. The performance scales linearly up to the number of physical cores involved in the capturing process, 6 in my case. The second 6 cores are in reality virtual cores, rendered by the Intel hyper-threading machinery.

PFQ capturing system

My testbed shows that PFQ can capture and copy to userspace up to 10 Million 12.5 Millions (42 Millions with copies) packets per seconds (64-bytes long) by deploying 6 cores @2.66Ghz in the capturing process and the multi-queue Intel 82599 ethernet adapter.

With a recent optimization, the CPU load-average is about 25% (per core) 15% per core. In comparison, the PF_PACKET socket, when used in memory map mode as in pcap library, can capture no more than few hundred thousand or so packets per second.

The PFQ source code is available for download at github: https://github.com/pfq!

Enjoy!

Nicola

Wikipedia defines IoC (Inversion of Control) as an abstract principle that describes an aspect of some software architecture design in which the flow control of a system is inverted in comparison to procedural programming. According to Martin Fowler, the term IoC is at least dated 1988, but, it’s still unclear whether it can be considered a pattern or just an architectural principle.

Although IoC is a generic principle, concrete implementations depend on the semantics in play. Indeed, in the everyday C++ programming, IoC can be found in different forms. Among them:

• Pointer to functions (callback)
• Generic Programming: STL algorithms, functors and callable objects
• Polymorphism and NVI idiom
• Policy Classes
• Strategy pattern and std::function
• Lamba functions and closures

The listed idioms differ each other, but the principle on which they are based is common: to provide a means for customizing an algorithm, improving both software decoupling and code reusability. In particular, the principle focuses on the separation between the code implementation and the execution.

In this essay we will examine different idioms, pointing out the properties that each one has in common with the IoC principle. In doing so, we will put emphasis on some possible implementations with respect to the C/C++ and the upcoming C++0x language.

Pointers to function

Pointer to function is the more ancient means that implements IoC. Even if most modern programming language got ride of them, pointers are supported by both C and C++ language and today still represent a valuable programming element.

Pointer to functions allow to customize a generic algorithm by means of callbacks. As an example the  GNU C library, which provides functions for searching and sorting arrays of arbitrary objects.

Let’s examine qsort:

qsort (void *array, size_t count, size_t size, comparison_fn_t compare)

The third argument, comparison_fn_t type, defined as “int comparison_fn_t (const void *, const void *)”, is the signature of the callback. The client code is supposed to provide a congruent comparison function in order to specialize the sort algorithm. For example:

     int
     compare_doubles (const void *a, const void *b)
     {
       const double *da = (const double *) a;
       const double *db = (const double *) b;

       return (*da > *db) - (*da < *db);
     }

The advantage of pointers to function in comparison to other semantics is the ability to customize an algorithm with a callback whose address can even be unknown at compile time (for example with functions dynamically loaded at run time from a shared library). The other side of the coin is that this feature results in a performance penalty, a major drawback if compared to other mechanism provided by  C++ and templates.

Generic Programming: STL algorithms, functors and callable types.

One of the big wins of C++ over C is represented by the templates, a semantic that enables generic programming. The Standard Template Library today is an exceptional example we all have something to learn from. More importantly, not only is it possible to customize generic STL algorithms by means of function pointers, but also it is possible to pass callable objects at the instantiation point (instances of callable types).

A callable type is defined as:

• a pointer to function
• a pointer to member function
• a pointer to member data
• a class type whose objects can stand at the left-hand side of a function call operator, that is a class that implements the operator() or a conversion to a pointer to function.

At the instantiation point, there’s no difference between passing a function pointer or an instance of a callable object as argument to a template function.

    template <typename Fun>
    void algorithm(Fun f)
    {
        f(arg1, arg2, ...);
    }

The function algorithm can either take a pointer to function or an instance of a callable type: both must have a matching signature.

A classic callable object is represented by functor, that is a class that implements the operator():

    struct generic_functor
    {
        void operator()(int arg1, arg arg2, ....) const
        {
           ...
        }
    };

Unlike a pointer to function, a functor can have a private state that can be accessed across different executions. Unfortunately, the standard does not specify that the STL algorithms must not make internal copies of the passed functors. As a result, the client code cannot take advantage of this, and this reason explains why the instances of callable types are usually passed to algorithms as temporary objects. Yet, passing a functor by std::ref() may lead to wrong results, if later we expect to find a consistent state as it were never copied.

The sole exception to this is represented by std::for_each algorithm, which returns a copy of the callable object in order to expose to the client code the state of the object utilized during the iteration. std::for_each guarantees that the instance of the function used during the iteration is unique.

    generic_functor out = std::for_each(vec.begin(), vec.end(), generic_functor());

In term of performance, there’s an important difference between calling a pointer to function and invoking a functor. In particular, the code of the operator() can be inlined into the algorithm, while the code of a function referred by a pointer can’t be because the value of the pointer is known at runtime (even if in some cases it could be statically determined at compile time).

The C++ standard provides a rich set of functors in the header <functional>. Among them, std::greater<> and std::less<> predicates that can be used to customize algorithms with different way to compare objects. For example, it’s possible to customize the std::sort in order to obtain a vector of integers sorted into descending order:

    std::sort( vec.begin(), vec.end(), std::greater<int>());

Polymorphism and NVI idiom

Another important lesson to learn from STL is that virtual functions should never be declared public. This principle, known as NVI idiom (Non Virtual Interface) or “the template method”, enables pre-condition and post-condition checking of virtual functions.

The NVI idiom, behind his back, can used to implement the IoC principle on the top of the inheritance polymorphism. The idea is simple: the base class exposes public methods implemented in term of the protected virtual functions provided, in turn, by the concrete class.

One important example of NVI idiom is, for example, the std::streambuf class, a class provided by the standard library to implement user-defined stream buffers. Streambufs are meant to customize the std::stream class, in order to accomplish the operations of read and write of character sequences.

As an example, my membuf class, a streambuf that can be used to stream from/to in-memory buffers:

    struct membuf : public std::streambuf
    {
        membuf(char *buffer, size_t size)
        {
            this->setp(buffer,buffer+size);
            this->setg(buffer,buffer,buffer+size);
        }

        char *end()
        {
            return this->pptr();
        }
    };

Policy class

Policy-based class design was first presented by Andrei Alexandrescu in the book Modern C++ Design. To repeat his words, the policy class is a technique that enables the creation of flexible, highly reusable template libraries. Such a design enables the separation of the implementation from the generic aspects of a class, increasing software decoupling, especially when multiple policies are concurrently deployed.

A policy-class can be, but it’s not limited to, a struct containing static methods that embody the details of the implementation. The classes that belong to the same policy are syntax oriented, and must respect the interface defined by the policy itself. Whether the policy-class or the included methods are templated, instead, is a matter of implementation.

A template class based on policy-classes is called host class and it’s where the magic of IoC happens. Policy-classes are passed to the host in different manners: as a template argument if the policy class includes only static methods, by means of inheritance otherwise.

Such a host class takes advantage of the implementations provided by the policy-classes at its instantiation point. Unlike the NVI, which is implemented by means of polymorphic inheritance, the host class enables IoC with no performance penalty, thanks to the static methods mixed-in by templates or by the non-polymorphic inheritance (the policy class has no virtual functions).

The policy class is similar to a traits class and differs from it only in that it’s more focused on the behavior rather than on the properties of the type. Also, the policy-class revamps the implementation of the Strategy pattern with compile-time bindings.

The C++ standard has an important example of policy-class: the std::char_traits, which is used to customize the behavior of the std::basic_string. Despite the name, indeed, char_tratits is a policy class rather than a traits class.

Strategy pattern and std::function

The strategy pattern is a particular design where the algorithms to run is dynamically selected. It is the ancestor of the policy-class: it provides the same functionality, with the difference that the binding with strategies happens at runtime, while the binding with policies does at compile time.

While different implementations are possible, the most convenient one is by means of  C++0x  std::function(or std::tr1::function available with C++03). Strategies, indeed, can be implemented with pointers to function or by means of polymorphic functors (with a common interface).

The std::function extends the strategy pattern with the ability to capture any kind of callable object with a consistent signature. The std::function allows to pass a function pointer to the strategy that later can be replaced with an instance of a callable object. All of this is possible thanks to the type erasure mechanism, a technique buried inside its implementation.

An example of a strategy-based class is:

    class strategy_based_class
    {
        typedef std::function fun_type;

        void set_compare(const fun_type &cmp)
        { _M_compare = cmp;}

        fun_type get_compare() const
        { return _M_compare; }

        void algorithm()
        {        ....
             if(_M_compare(a,b)) {
                 ....
             }
        }

    private:
        fun_type _M_compare;
    };

Like the other idioms, the use of std::function can be interpreted as an implementation the IoC principle: the stategy class can focus on the execution rather than on the implementation, demanded to the std::function itself.

Lambda functions and closures

The C++0x introduces a new kind of callable type, directly implemented in the core language: the lambda function. However, lambdas are not a real news in the C++ language. The boost library already implemented it (on the top of c++03) by means of the magic template metaprogramming.

Lambdas are a means to implement anonymous functions that can be declared inline, right where you need them. It’s possible to declare a lambda at the instantiation point of a generic algorithm, without the need to declare the callable type with global visibility. The use of lamba functions is very handy and effective.

Lambdas have also the ability to refer to identifiers declared outside the lambda itself, much like the nested functions of the C language. A lambda function that access to external variables is known as closure, in honor to the Lips language.

With respect to IoC, lambdas are just another way to customize a template function/algorithm, like those of STL, and they are also assignable to a std::function<> with a compatible signature.

As examples, the std::sort of a container in descending order and the accumulate algorithm, implemented by std::for_each, both in term of lambda functions.

    std::sort(vec.begin(), vec.end(), [](int a, int b) { return a > b; });

and

    int sum = 0;
    std::for_each(vec.begin(), vec.end(), [&sum](int n) { sum += n; });

The original article of Martin Folwer covers more detailed aspects of IoC, especially from the point of view of the Java language.  Also more information can be obtained at http://martinfowler.com/bliki/InversionOfControl.html.

In this essay I covered the IoC pattern, presenting some implementations from the point of view of the expressive C++ language. While the acronym IoC is not so common in the C++ world, its meaning can be found in very different forms: it’s a matter to distinguish it in a plethora of semantics.

Enjoy C++0x, always.

For those who have never heard about metafuncions I would suggest to read a couple of books,  C++ Modern Design Pattern and the more specific C++ Template Metaprogramming. To make the long story short,  a metafunction is a function that runs at compile time. The technique was discovered by Erwin Unruh  years ago when he created a C++ program that, though not compiling, was able to generate the sequence of prime numbers in form of  compiler error messages.

Today metaprogramming has become a very refined technique widely exploited in a number of C++ template libraries, boost to mention one. A didactic example of a numeric metafunction is the factorial:

template <int N>
struct factorial
{
    enum { value = N * factorial::value };
};

template <>
struct factorial<0>
{
    enum { value = 1 };
};

An important achievement of the last years, presented by Alexandrescu in Modern Design Pattern, is the type list, that is a recursive agglomerate of types that resembles to a list of types. The type list enables implementations of different classes, tuple and variant to mention a few.

A possible implementation of a type list is the following one:

struct null {}; // typelist terminator

template <typename H, typename T>
struct typelist {};

typedef typelist< int, typelist< char, typelist< short, null> > > list_type; // list of int, char and short

…where the null type is a placeholder that identifies the end of the list. The list itself (list_type) is just a type. Therefore, to operate on it a set of metafunctions is required.

For instance, the following metafunction can be used to calculate the length of such a type list:

    // length<Tp>::value
    //

    template <typename Tp> struct length;
    template <>
    struct length<null>
    {
        enum { value = 0 };
    };

    template <typename T,typename U>
    struct length< typelist<T,U> >
    {
        enum { value = 1 + length<U>::value };
    };

By means of templates and recursion it is possible to implement a complete set of meta-functions, like adding a type to the head, to the tail and so forth.

However, VTA allows to express the type-list in a better way and in this essay I present a possible novel implementation along with some variadic companion metafunctions.

That said, a new definition of a typelist could be the following one:

    template <typename ...Ti>
    struct type_list {};

It follows that the declaration of a type-list looks like this:

    type_list<int, char, double>

which is very compact declaration in comparison to those enabled by means of C++03, that in the best case use some preprocessing macros to hide the boilerplate declaration.

This new list requires variadic metafunctions to perform operations on it. For instance, the metafunction that calculates the length of such a list is the following one:

    // length<>::value
    //
    template <typename Tl> struct length;

    template <typename T, typename ...Ti>
    struct length<typelist<T, Ti...>>
    {
        enum { value = 1 + length<typelist<Ti...>>::value };
    };

    template <typename T>
    struct length<typelist<T>>
    {
        enum { value = 1 };
    };

    template <>
    struct length<typelist<>>
    {
        enum { value = 0 };
    };

A better non-recursive implementation is based on the sizeof…() operator that, when applied to a parameter pack, returns the number of the elements.

    template <typename Tl> struct length;
    template <typename ...Ti>
    struct length<typelist<Ti...>>
    {
        enum { value = sizeof...(Ti) };
    };

It’s worth noting that by means of  VTA the implementation of meta-functions like insert and append result much simple:

    // append<>::type
    //
    template <typename Tl, typename Tp> struct append;
    template <typename Tp, typename ...Ti>
    struct append<typelist<Ti...>, Tp>
    {
        typedef typelist<Ti...,Tp> type;
    };

    // insert<>::type
    //
    template <typename Tl, typename Tp> struct insert;
    template <typename Tp, typename ...Ti>
    struct insert<typelist<Ti...>, Tp>
    {
        typedef typelist<Tp, Ti...> type;
    };

The other companion functions that a typelist should be implementing are not provided herein. I leave the reader with the pleasure to implement them as a brain teaser. All in all, an important part of coding is the fun.

Enjoy the C++0x, always!

In turn, the variadic template arguments [VTA], along with the r-value reference that allows the perfect forwarding, enable users to design very compact patterns with a high level of code re-usability, opening the doors to a new way of writing generic code.

Up until now, we have emulated VTA by replicating the source code of a class or function, providing the implementation for each number of arguments we wanted it to support. A more elegant way consisted in writing a single generic function (or class) accepting the maximum number of template arguments and providing a placeholder type, like struct null {},  to pad the unused arguments.

These solutions provided the users with the illusion of using VTA on the top of C++03, while leaving the effort of maintaining the boilerplate code to the library implementers, tempted to support a few numbers of arguments, typically four or five (uhm, I’m lazy).

VTAs on the top of C++0x are of a great help when it comes to implement a design pettern. The factory pattern is not an exception.

The factory is a very common pattern. If you have written about a thousand of code lines in your life, probably about 5% of them represent a factory. This pattern is also known as virtual-constructor idiom since it implements a polymorphic generic constructor driven by runtime values.

Some of the valuable points of the factory are listed below:

• it’s generic and can be reused (the extent of reusabiliy depends on the implementation…)
• it makes the code clean and extensible (without changing a single line in the client code)

If It’s true that for a library the implementation matters, for a reusable pattern it’s even more important. Basically the implementation of a factory I’m going to present consists in an associative container (a standard map) that maps an identifier into a polymorphic factory allocator, that is a template class in charge of allocating the concrete type, providing the arguments to its constructor.

Compared to the virtual constructor idiom of  Coplien this implementation does not make use of exemplars and that has an evident advantage in term of resource consumption: instances of elements are built on demand and not virtually cloned, nor copy-constructed! That’s a good point because exemplars may acquire resources only released at the factory destruction, or yet they may be not copyable/cloneable at all (because, for instance, just moveable).

In order to exploit the polymorphism the two classes factory_base_allocator and the generic factory_allocator are implemented in a IS-A relation:

template <typename B, typename ... >
struct factory_base_allocator
{
    virtual ~factory_base_allocator()
    {}

    virtual B * alloc(Arg&& ... ) = 0;
};

template <typename B, typename D, typename ... >   // B is a base class of D
struct factory_allocator : public factory_base_allocator<B,Arg...>
{
    static_assert(std::is_base_of<B,D>::value, "base_of relationship violated");

    virtual D * alloc(Arg &&... arg)
    {
        return new D(std::forward<Arg>(arg)...);
    }
};

The factory_base_allocator is a template class: the generic type B is the common base of all the types for whom the factory is the manger. The argument pack Arg is the list of types to be passed to the constructor of the concrete class. Arguments are taken by r-value reference and perfectly forwarded the proper constructor by means of the std::forward, an utility in charge to fix the argument deduction type: r-value if the provided argument is an r-value, l-value otherwise.

The factory_allocator ensures that the type D of the concrete class is in a IS-A  relation with the generic base class (B) my means of the type_trait std:::is_base_of<> and the valuable static_assert. This utility class implements the sole virtual method alloc supposed to construct the instance of D on demand.

Enjoy for a while the beauty of the virtual variadic method alloc: It implements a virtual perfect forwarder, a proof that that the implementation matters!

On the basis of this helper allocator, the implementation of the factory class results:

    template <typename K, typename T, typename ... Arg>
    class factory
    {
    public:
        typedef std::map<K, std::shared_ptr<factory_base_allocator<T,Arg...>>> map_type;

        factory()  = default;
        ~factory() = default;

        bool
        regist(const K & key, factory_base_allocator<T,Arg...> * value)
        { return _M_map.insert( make_pair(key, std::shared_ptr<factory_base_allocator<T,Arg...> >(value) ) ).second; }

        bool
        unregist(const K &key)
        { return _M_map.erase(key) == 1; }

        bool
        is_registered(const K &key) const
        {
            return _M_map.count(key) != 0;
        }

        template <typename ... Ti>
        std::shared_ptr<T>
        operator()(const K &key, Ti&& ... arg) const
        {
            auto it = _M_map.find(key);
            if (it == _M_map.end())
                return std::shared_ptr<T>();
            return std::shared_ptr<T>(it->second->alloc(std::forward<Ti>(arg)...));
        }

    private:
        map_type _M_map;
    };

In that book there is an entire chapter devoted to present a whirl of singleton patterns that Andrei Alexandrescu gracefully dissects with his fervid insight of the out most boundaries of the C++ language. Andrei presents a unique, portable, policy-based pattern (also implemented in his Loki library) which aims at covering most features required to build a perfect Singleton.

What? A singleton? Uhmkay, let’s rewind the tape.

A Singleton, as wikipedia reports, is a design pattern used to restrict instantiation of a class to one object. The usefulness of this pattern has been largely discussed: some consider the singleton a good pattern while others simply an anti-pattern because of the resource decoupling effect which it leads to.

That said, this essay is not meant to eulogize pros and cons of the singleton (after all it would be just a religious war). Instead some achievements of Anadrei are summarized and a candidate for a C++ implementation of the perfect singleton is discussed from the perspective of the GNU compiler.

In his book Andrei addresses two major issues that affect the popular singleton implementations: The thread-safety and the dead reference problem.

Concerning the thread safety, the singleton pattern is supposed to guarantee the uniqueness of the instance, even among different threads. As a result, if a singleton implementation makes use of the construction-on-the-first-use idiom (which returns a local static instance), a locking mechanism is required to prevent threads from constructing multiple instances at the first concurrent access.

That said, the responsibility to build a unique instance goes to the singleton implementation, while the rest of thread-safe constraints are of course up to the class writer. As corner case you may consider a singleton class with no mutable members that returns a const reference to the unique instance. The critical part of such an implementation is the construction, since the subsequent accesses are not required to be atomic at all (the object is constant).

For this issue Andrei presents two popular patterns: the locking singleton (faulty because of the implicit race condition) and the double-checked locking singletons (Douglas Schmidt) which aims at fixing the former race but that under certain architecture/compiler is still faulty (memory barriers are required to carry out a correct double-checked singleton pattern).

The second issue addressed is the dead reference problem. Basically the problem is related to the order of destruction of dependent singletons. At the program’s exit if a singleton destructor makes use of an already destroyed singleton, an undefined behavior occurs (most probably a segfault).

Andrei presents a couple of patterns that overcome this problem. The first one is the phoenix singleton, a special implementation supposed to re-build the instance on demand at the memory address it had before the destruction. The second one is the singleton with longevity, a design which provides a mechanism to control the order of the singleton destructions (by means of a priority queue).

As final aim all the patterns described in the book are blended into a unique, policy-based singleton: the SingletonHolder. The pattern presented is portable and allows the mix of different features, providing the user with a practical way to express her needs in a single definition.

This is the end of the story, period. But you have an overwhelming wish to undergo with a vivid hallucination, take a breath.

Let’s go about things in an orderly way.

First, the Meyers Singleton is dissected to proof it is a robust pattern if compiled with the GNU g++-4.x. Second, a list of attractive requirements for a perfect singleton is provided. Then, a novel, generic singleton implementation is presented.

Okay, I have to admit it. I have loved the Meyers singleton since the first time I studied it (love at first sight?). Meyers presents a very practical way to carry out a singleton class:

class single
{
    public:
    static single &
    instance()
    {
        static single one;
        return one;
    }

    private:
        single()
        {}
        ~single()
        {}

        single(const single &);
        single &operator=(const single& );
};

The properties of the Meyers singleton are listed below:

1. The class is not instantiable because both default constructor and destructor are private.
2. The class is not copy-constructible, nor assignable because both copy constructor and assingment operator are private and not implemented.
3. It is only possible to get a reference to a single instance (one) by means of the static method instance();

The instance is constructed on demand (the first time the instance method is called) and destructed at the program’s exit, in the reverse relative order of which other static objects (and potentially other singletons) are constructed.

single &ref = single::instance();

This class looks great and indeed it is. But what exactly were the reasons that made Andrei to abandon this implementation?

Basically Andrei left it out because it does not provide a means to control the order destruction. In my experience the dead reference problem is a minor problem because it is not common and shows up only when a singleton depends on another singletons during its descruction.

In my opinion what really matters is instead whether a singleton is supposed to be destructed or not at the program’s exit.

If the singleton is not, then the Meyers’ implementation needs a minor change in the static member: The instance is allocated in the heap by means of the new operator and it will not be automatically destroyed at the program’s exit.

static single &
instance()
{
    static single * one = new one;
    return *one;
}

On the other hand, if the singleton is supposed to be destroyed at the program exit and it depends on other singletons that must be destroyed as well, it is possible to control the order of the destructors by accessing their instances at the beginning of the program in the right reverse order:

single_2::instance();
single_1::instance();

This is sufficient to fix the dead reference problem, which seems to be a minor problem that, all in all, it’s not worth striving for.

The second issue to cope with is the race condition which affects the constructor at the first invocation. Even if the standard does not guarantees anything about this issue, starting from the g++ 4 the initialization of function-scope static variables is thread-safe by default. This means that a singleton pattern that relies on local static variables is automagically made thread safe because the constructor is atomic.

The following snippet proves this concept:

struct poc
{
     poc()
     {
         std::cout << "building..."; std::cout.flush(); sleep(5);
         std::cout << "done\n";
     }

     ~poc()
     {
         std::cout << __PRETTY_FUNCTION__ << std::endl;
     }

     static poc &
     instance()
     {
         static poc one;
         return one;
     }
};

void * thread(void *)
{
     poc &r = poc::instance();
}

int main(int argc, char *argv[])
{
     ...
     pthread_create(&thread_1, NULL, thread, NULL);
     pthread_create(&thread_2, NULL, thread, NULL);
     ...
}

here’s the disassembled code of the static function poc::instance():

(gdb) disassemble 'poc::instance()'
Dump of assembler code for function _ZN3poc8instanceEv:

0x0000000000400cb2 <_ZN3poc8instanceEv+0>:      push   %rbp
0x0000000000400cb3 <_ZN3poc8instanceEv+1>:      mov    %rsp,%rbp
0x0000000000400cb6 <_ZN3poc8instanceEv+4>:      sub    $0x30,%rsp
0x0000000000400cba <_ZN3poc8instanceEv+8>:      mov    $0x601428,%eax
0x0000000000400cbf <_ZN3poc8instanceEv+13>:     movzbl (%rax),%eax
0x0000000000400cc2 <_ZN3poc8instanceEv+16>:     test   %al,%al
0x0000000000400cc4 <_ZN3poc8instanceEv+18>:     jne    0x400d4f <_ZN3poc8instanceEv+157>
0x0000000000400cca <_ZN3poc8instanceEv+24>:     mov    $0x601428,%edi
0x0000000000400ccf <_ZN3poc8instanceEv+29>:     callq  0x400988 <__cxa_guard_acquire@plt>
0x0000000000400cd4 <_ZN3poc8instanceEv+34>:     test   %eax,%eax
0x0000000000400cd6 <_ZN3poc8instanceEv+36>:     setne  %al
0x0000000000400cd9 <_ZN3poc8instanceEv+39>:     test   %al,%al
0x0000000000400cdb <_ZN3poc8instanceEv+41>:     je     0x400d4f <_ZN3poc8instanceEv+157>
0x0000000000400cdd <_ZN3poc8instanceEv+43>:     movb   $0x0,-0x11(%rbp)
0x0000000000400ce1 <_ZN3poc8instanceEv+47>:     mov    $0x601430,%edi
0x0000000000400ce6 <_ZN3poc8instanceEv+52>:     callq  0x400c72
0x0000000000400ceb <_ZN3poc8instanceEv+57>:     movb   $0x1,-0x11(%rbp)
0x0000000000400cef <_ZN3poc8instanceEv+61>:     mov    $0x601428,%edi
0x0000000000400cf4 <_ZN3poc8instanceEv+66>:     callq  0x4009f8 <__cxa_guard_release@plt>
0x0000000000400cf9 <_ZN3poc8instanceEv+71>:     mov    $0x400c48,%edi
0x0000000000400cfe <_ZN3poc8instanceEv+76>:     mov    $0x6012e8,%edx
0x0000000000400d03 <_ZN3poc8instanceEv+81>:     mov    $0x601430,%esi
0x0000000000400d08 <_ZN3poc8instanceEv+86>:     callq  0x4009b8 <__cxa_atexit@plt>
0x0000000000400d0d <_ZN3poc8instanceEv+91>:     jmp    0x400d4f <_ZN3poc8instanceEv+157>
0x0000000000400d0f <_ZN3poc8instanceEv+93>:     mov    %rax,-0x28(%rbp)
0x0000000000400d13 <_ZN3poc8instanceEv+97>:     mov    %rdx,-0x20(%rbp)
0x0000000000400d17 <_ZN3poc8instanceEv+101>:    mov    -0x20(%rbp),%eax
...

The calls __cxa_guard_acquire/__cxa_guard_release are injected by the compiler to make the spell: the construction of static variables/objects is atomic. Yet, the __cxa_atexit function is used to register the destructor for the static object called at the program’s exit (note that it’s also possible to prevent the guard injection by passing the option -fno-threadsafe-statics to g++ at compile time).

Cool. G++ makes the Meyers Singleton robust and thread-safe. It seems to be a perfect candidate for the our singleton, but some features are still missing. Here’s the wish-list:

• You’d like a generic singleton implemented by means of CRTP pattern:

class single: public more::singleton<single, ... >
{

• You’d like a generic singleton that enables various flavors: destructible (at the application’s exit) or indestructible:

class single : public more::singleton<single, more::singleton_type, ...>
{
    // or

class single : public more::singleton<single, more::indestructible_singleton_type, ...>
{

• You’d like a generic singleton that allows to CV-qualify the instance:

class single : public more::singleton<single, const more::singleton_type, ... >  // both cv qualifiers should be enabled
{

• You’d like a generic singleton that once a class publicly derives from it:

1. It is not instantiable (*).
2. It is not copyable, nor copy-constructible.
3. It inherits the static method instance() returning the CV-qualified reference (simple, const or volatile) of the instance created at the first access.

• You’d like a generic singleton that allows a non-default constructible class to be a singleton.

The parameters passed to the constructor will make sense only at the first access, and they should be ignored in the subsequent calls. Also it would be nice if it was possible to specify the types of the constructor parameters by means of a TYPELIST:

class single : public more::singleton<single, more::singleton_type, TYPELIST(int)>
 {
    ...
    single(int value)
    : _M_member(value)
    {}
    ....

and somewhere in the code:

single & ref = single::instance(10); // build the instance passing 10
single & ref = single::instance();   // access the instance and take a reference

Such a singleton implementation is available here, and except for the feature marked with (*) possible only with a minor trade-off, its design consists in a mixture of template meta-programming and TR1 type traits.

Just few notes about the necessary trade-off. Since is not possible to obtain a class deriving from a generic base that inherits a static member function supposed to build an instance of it (while the class itself is not to be instantiable), the only way to fulfill this requirement is to add to the class constructor an additional parameter defined private in the base class and only accessible from the static member.

Such additional parameter (base_type::tag) must be passed to the constructor as first argument:

class single : public more::singletonTYPELIST(std::string, int)>
{
    single(base_type::tag, const std::string &s, int n)
    {}
};

That’s all folks. If you are far-seeing you can play with my Singleton and then use it in your projects, but don’t forget to buy me a beer in return.

To be perfect a forwarder must be able to be deployed in different contexts, allowing to pass both lvalue and rvalue parameters, yet having the template parameter types correctly deducted and the target function properly chosen from a possible overloaded set.

The current C++ standard does not allow to implement such a perfect forwarder that instead is enabled by means of C++0x rvalue reference. Nevertheless, a generic non-perfect but correct forwarded is possible with the help of tr1::reference_wrapper.

The most desirable feature for a generic wrapper is a mechanism for passing the arguments to a target function that accepts them in different ways: by copy, by reference and by const reference.

The client of the generic forwarder, indeed, must be able to pass either lvalue or rvalue arguments in accordance with the target’s signature: that is if a target parameter (the parameter of the target function) is taken by non-const reference, the corresponding parameter passed to the wrapper should be provided accordingly (as lvalue).

In this study a comparison of three different forwarders is presented, introducing the concept of perfect forwarding enabled by means of rvalue references.

The following  function has been chosen as target object (it could be a functor or any other callable object):

int fun(arg a1, const arg &a2, arg &a3)
{
    a3 = arg(1);
    ...
    return 0;
}

The first signature examined is the following one:

template <typename F, typename T1, typename T2, typename T3>
int candidate_forwarder_1(F &f, T1 &t1, T2 &t2, T3 &t3)
{
    return fun(t1,t2,t3);
}

All the arguments are passed by non-const reference.

The candidate_forwarder_1 sports no performance loss in that no additional copy constructors are called during the parameters passing (comparisons are provided by test #0 and #1). However such a wrapper has a flaw: The caller of this wrapper is not allowed to pass a temporary object although the target function was designed to accept it by value or by const reference (ie: the second parameter of function fun).

This weakness is a consequence of a rule imposed by the standard that does not allow a non-const reference to bind an rvalue. The rule is intended to prevent the modification of an rvalue (temporary object) that, prior to the understanding of the importance of the move and forward semantic of C++0x, did not make much sense.

To get out of this scrape a second candidate for the perfect forwarder is considered:

template <typename F, typename T1, typename T2, typename T3>
int candidate_forwarder_2(F f, T1 t1, T2 t2, T3 t3)
{
    return fun(t1,t2,t3);
}

In this wrapper all the arguments are passed by value, which means that it’s possible to pass both lvalue and rvalue. However there’s a double problem here: not only are the arguments copy-constructed, but also the type deduction decay now comes into play. The decay makes array and function types resolved as pointers, as well as the top-level CV qualifiers discarded (see template argument deduction decay: C++ Template: the complete guide [Vandevoorde/Josuttis]).

As a consequence this second candidate shows following problems:

1. it’s not perfect due to the template argument deduction decay. The template argument types may be resolved as types that cannot be used to select the proper target function (overloading failure).
2. parameters of the target function taken by reference are bound to the formal parameters of the forwarder (t3, in the example) and not to those provided by the forwarder client.
3. parameters are passed by value and additional copy constructors are involved.

The test #2 shows that the issue 2 makes this wrapper incorrect:

Fortunately a workaround exists: the tr1::reference_wrapper class can be used to wrap the arguments supposed to be passed as non-const reference to the target function.

Hence if the instantiation point is like just this one:

candidate_forwarder_2(fun, a1, a2, std::tr1::ref(a3));

the wrapper produces the expected result. Test #3 and #4 show the correctness of the forwarder function.

Alas the comparison of the test #0 and #4 shows further copy constructors involved when passing the argument a1 and a2 (*3). This is the price to pay to implement a wrapper that can accept both lvalue and rvalue parameters.

It’s worth noting that when passing an rvalue object no additional copy constructor is involved thanks to the copy elision optimization implemented in most of the compilers available today. The test #3 shows such an optimization in action:

candidate_forwarder_2(fun, arg(), arg(), std::tr1::ref(a3));

In despite of the sub optimal performance pointed out by the test #4, the candidate_forwarder_2 wrapper is however preferable over the candidate_forwarder_1, in that it admits rvalues and temporaries as arguments.

Although not perfect (*1), it’s the most convenient implementation the current C++ standard allows to implement. The object adapter tr1::bind, for instance, is written exactly this way.

As final candidate, the perfect forwarder is presented. It is implemented by means of C++0x rvalue reference:

template <typename F, typename T1, typename T2, typename T3>
int the_perfect_forwarder(F f, T1 &&t1, T2 &&t2, T3 &&t3)
{
    return fun(std::forward<T1>(t1),
               std::forward<T2>(t2),
               std::forward<T3>(t3));
}

The limitation that a non-const reference cannot bind an rvalue is removed by means of the rvalue reference [&&] which is supposed to bind to both lvalues and rvalues when it’s a template parameter.
Bearing in mind the  reference collapsing rules introduced by C++0x :

• T& -> & -> T&

• T& -> && -> T&

• T&& -> & -> T&

• T&& -> && -> T&&

The last forwarder sports the following properties:

• No additional copy constructors are involved during the argument passing.

• Either a lvalue or an rvalue can be provided as argument, in accordance with the signature of the target function/object.

• The template argument deduction for an rvalue reference is done in the following way:
  • if a lvalue of type A is passed, T resolves to A& and by the reference collapsing rules, the argument type becomes A& (lvalue reference);
  • if an rvalue is passed, T resolves to A, and the argument type becomes A&& (no collapsing rule is applied).

However the rvalue reference itself is not sufficient to implement a perfect forwarder because once the arguments are passed to the wrapper they have a name and therefore they all are l-values. To restore their original type the std::forward<> helper function can be used to implement the correct forward semantic:

namespace std
{
    template <typename T>
    && forward(T&& a)
    {
        return a;
    }
}

Why std::forward<> is required? Let’s do an in-depth examination:

• If a lvalue of type A is passed to std::forward<> as argument, the corresponding type T of the wrapper resolves to A&. Then by the collapsing rules, the argument and the return type of std::forward become A&.

• If a rvalue of type A is passed to std::forward<> as argument, the corresponding type T of the wrapper resolves to A. Then the argument and the return type of std::forward become A&&.

That said, the return type of std::forward<> depends on type explicitly specified in the template at the instantiation point (argument deduction is not used in the std::forward). If it’s not yet clear, the following rule puts more light on the problem:

Objects declared as rvalue reference can be either lvalues or rvalues. The distinguishing criterion to bear in mind is: if the instance has a name then it is a lvalue; an rvalue otherwise.

In accordance with this criterion it follows that:

The return type of std::forward is an expression that (since it has no-name) it is an rvalue reference when an rvalue object is passed as argument, or a lvalue reference otherwise.

The std::forward template function used in the perfect forwarder returns an expression whose type is exactly the same as that of the argument passed to the wrapper. This enables the perfect forwarding.

Ciao

My name is Nicola. I’m a determined hacker, a unix hacker by choice and attitude. I have been an enthusiastic linux programmer since 1995. I have developed opensource applications using i386 AT&T assembler, GNU C and recently C++ languages solely for fun. I believe in the opensource philosophy, I am debian addicted and more importantly I love snowboarding.

After the masters in telecommunication engineering I worked for some years at the department of Information Engineering of the University of Pisa (Italy) as research assistant. My research activity focused the performance evaluation and optimization of device drivers of network adapters.

During that time I developed brute, actually the fastest and the most reliable traffic generator available for the linux operating system. Brute outclasses paired software in terms of performance and accuracy, providing users with a set of API that eases the development and enables the customization of generic traffic models. Brute was presented at SPECT05, an international SCS conference held in Philadelphia.

Another research project I worked on is a linux LKM intended to handle classifiers and schedulers at link layer of the 802.11 wireless protocol. L2FW, the name of the framework, is built on the top of the HostAP driver with the aim to improve the performance of Prims2 adapters when running as AP. On the top of L2FW with the guidance of Rosario Garroppo and Stefano Lucetti I then developed a channel-aware scheduler that, in conjunction with a mac classifier, avoids the performance anomaly of 802.11[bg] wireless networks.

Among other projects, it’s worth mentioning a linux interrupt-handler hack (do_IRQ) — a work I sketched with my colleague Francesco Oppedisano. The hack aims at implementing a refurbished version of NAPI that we could name New NAPI (NNAPI). NNAPI aims to fill the gap left about the capability to timestamp packets in gigabit ethernet device drivers (tests were conducted with intel epro1000 ethernet adapter). From the traffic characterization point of view, in fact, the accuracy of NAPI timestamping is not adequate and needs to be improved. NNAPI enhances the accuracy of timestamps by three order of magnitude — cloned timestamps pass from some thousand to a few.

A uber-lightweight interrupt handler that sports a minor latency reduced roughly to that of the interrupt PIC replaces the interrupt mitigation scheme. Unfortunately, quite predictable, the high precision of timestamping is achived to a detriment of performance in terms of packets captured per second. The project needs to be refined a bit. Hopefully the NNAPI source code will be released someday.

At the present moment I am employed at a company operating in the information and communication technology sector. I left the academic world last January.