Anthony Williams is author of the book C++ Concurrency in Action and of the just::thread C++0x thread library. He can be contacted at anthony.ajw@gmail.com

"Concepts" was set to be one of the major selling points of the new C++0x standard, until it was removed from the draft in July 2009. The "Concepts" feature promised better compile-time checking of templates, and the ability to overload functions based on whether or not their parameters supported specific templates.

In this article I look at some techniques for obtaining some of the benefits of concepts, with the facilities we already have in C++. Source code that illustrates these techniques is listed at the end of this article.

Basic Tools

The basic tools we need for concept checking and concept-based overloading are static_assert, enable_if, and a particular property of template instantiation dubbed SFINAE (short for "Substitution Failure Is Not An Error").static_assert is useful for the checking, enable_if for the overloading. SFINAE is the mechanism that makesenable_if work, and can be used to write additional checks for testing with static_assert or enable_if.

static_assert is a new C++0x language feature, and is available in the latest versions of some compilers, such as Microsoft Visual Studio 2010 and g++ 4.3 or later. It allows you to specify a boolean constant expression and an error message -- if the constant expression evaluates to False at compile time then the compilation fails and the specified error message is output. For example, this simple program compiled with gcc -std=c++0x:

    int main()
    {
        static_assert(false,"your message goes here");
    }

yields this error message:

    test.cpp: In function ‘int main()‘
    test.cpp:3: error: static assertion failed: "your message goes here"

The constant expression can of course depend on template parameters, and that‘s where the checking comes in: if you put a static_assert in a template then the compilation will fail if the specified condition is not True, and the error message will be a lot clearer than what you would get otherwise.

static_assert works really well with the standard type traits -- you can assert that a given type is convertible tobool, or is derived from a particular base class, or is a POD. Of course, you can also define your own traits for any characteristic that you can build a test for. Later in this article I‘ll show how you can build a test for the presence of particular member functions.

You could, for example enforce the constraint that a particular template parameter is a POD type, so you can copy instances with memcpy:

    template<typename T>
    void copy(T const* source,T* dest,unsigned count)
    {
        static_assert(std::is_pod<T>::value,"T must be a POD");
        memcpy(dest,source,count*sizeof(T));
    }
is

If you try and use this copy function with a non-POD type such as std::string, then you will get a compilation error.

The Boost Concept Check Library provides an alternative to static_assert for checking for concept conformance. Just like static_assert, it generates compiler errors if the concept is not matched. However, it may provide an easier way of specifying the constraints than plain static_assert if concept-based overloading is not required.

Whereas static_assert is all about hard and fast requirements, enable_if is about choices. You use it to enable certain function overloads if and only if a given property is True. This enables you to specify different versions of an algorithm based on the properties of the template parameters.

For example, you could use enable_if to use memcpy when copying PODs, rather than copying each element individually:

    template<typename T>
    typename std::enable_if<std::is_pod<T>::value,void>::type
    copy(T const* source,T* dest,unsigned count)
    {
        memcpy(dest,source,count*sizeof(T));
    }

    template<typename T>
    typename std::enable_if<!std::is_pod<T>::value,void>::type
    copy(T const* source,T* dest,unsigned count)
    {
        for(unsigned i=0;i<count;++i)
        {
            *dest++=*source++;
        }
    }

enable_if is quite simple in and of itself -- if the first template parameter (which must be a boolean constant expression) evaluates to true then the nested "type" member is a typedef to the second template parameter. If the the first parameter evaluates to False then there is no nested "type" member.

The SFINAE rules mean that if enable_if<some-expression,some-type>::type is used in the signature of a function template (as here), then that function overload is discarded if some-expression is False -- that overload is only enabled if some-expression is True.

SFINAEThe basic premise of SFINAE is that when the compiler is deducing the template parameters for a function template from a function call, if the deduced parameters would make the signature invalid then that function template is not considered for overload resolution rather than resulting in a compilation failure. There are limits, and some template instantiation errors will still cause compilation failure, but this is the basic principle that makes enable_if work.

For example, given the function template:

    template<typename T>
    typename T::type foo(T t)
    {}

If you try and call foo(3), then T is deduced to be int. The type int does not have a member called type. The instantiation is therefore invalid when substituting "int" as the template parameter. By the SFINAE rule, this is not an error: instead the overload is ignored. If there is another overload of foo that can match foo(3), then that will be chosen instead. Of course, if there are no other overloads or none of the others match, then you still get a compilation error.

SFINAE does not work if the required instantiation of the function template depends on the instantiation of another template and that instantiation fails; for example:

    template<typename T>
    struct bar
    {
        typedef typename T::type type;
    };

    template<typename T>
    typename bar<T>::type foo2(T t)
    {
        // ...
    }

If you call foo2(3), then T is again deduced as int. However, bar<int> cannot be instantiated, since int does not have a member called type. This is a failure in the instantiation of bar<int> , not in the instantiation of foo2<int>, so is a real compiler error, and will not be ignored by SFINAE.

Availability of Features

Newer compilers (such as gcc 4.3 or later, and Microsoft Visual Studio 2010) are starting to provide C++0x features. static_assert is one of the most common C++0x language features added to compilers, but for those compilers that don‘t have static_assert, you can emulate it with BOOST_STATIC_ASSERT.

enable_if on the other hand is purely a library facility, and was part of the C++ Technical Report 1. As such it is even more widely available as part of the library supplied with compilers. For those compilers that don‘t provide their own version, it is also available as part of the Boost Library.

--A.W.