Version 1.00
Author: prototype
Copyright (C) 2004 prototype
Permission is granted to copy and redistribute this article provided that its contents (including the title, author information, and this copyright claim) are kept intact in the original form.
This software is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Abstract
The typelist and relevant concepts are introduced, together with a basic typelist implementation. An elegant, easy-to-use, and macro-free typelist generator is shown.
Introduction
Typelist, as its name suggests, refers to a (singly-) linked-list "data" structure with the data or elements being types. Like the conventional and more familiar singly-linked list data structure, typelist consists of a number of nodes that are arranged in a logically-linear fashion; specifically, each node conprises two fields: one, referred to as the "data field", holds the data (a type); the other one, referred to as the "pointer field", stores the information for finding the next node. The pointer field of the last node normally has a singular "value" indicating the end of the list. Typelist is as fundamental and important for C++ template metaprograming, which is becoming a crucial paradigm in moden C++ design and programming, as plain array for conventional programming. Examples of applications of typelist can be found in Andrei Alexandrescu's book: Modern C++ Design, and also in future installments of this C++ Metaprogramming series. Here I focus on a basic implementation of typelist and a solution to the interesting question: how to generate a typelist without C-type macros?
A basic implementation of typelist
Implementation of typelist can be amazingly simple as long as one knows how to store a data and how to represent a pointer in C++ template metaprogramming. The solutions to the two problems turn out to be the same -- use typedef. Let us take a look at an example to see how it works.
typedef int type; // Stores `int' to `type'.
type i; // `i' is of type `int'.
This simple example illustrates that after the typedef, `type' is remembered by the compiler to stand for `int' and thereafter wherever `type' is used, it will work as if it was literally replaced by `int'. This effect is exactly what we want -- using a symbol to represent a data (a type). With this understood, storing a data in C++ template programming is straightforward; while the pointer used in typelist can be considered as an alias to the next node, therefore it can also be implemented using a typedef.
A basic implementation of typelist can be something like
template <typename T, typename SL>
struct typelist
{
typedef T type;
typedef SL sublist;
};
Obviously, with this implementation, we want to use `type' to store the data in this node and `sublist' to store the pointer to the next node. To construct a typelist would be something like
typedef typelist<int, typelist<bool, ?> > tl2;
`tl2' here is a typelist with two nodes. In the first node, we store `int'; in the second node, `bool'. The `sublist' of the first node is `typelist<bool, ?>' -- the second node; but what about the `sublist' of the second node?
As I mentioned above we need a "singular" value for the pointer of the last node. So the `?' should be replaced by a type that is not used except for marking the end of a typelist. This type is easy to obtain, for example:
class null_type;
so the above `tl2' can be defined as:
typedef typelist<int, typelist<bool, null_type> > tl2;
This works. But it turns out the best value is actually something like `typelist<null_type, null_type>'. This value is much more convenient to use as will illustrated in future installments. Here I would like to rationalize it a little bit through an analogy to the singular value for a pointer in normal programs.
It is known that 0 is used as the singular value for pointers in normal C++ programs. This value has two basic characteristics: first, it is a legal pointer value, which means it can be assigned to any pointer object; second, it semantically means “nowhere” in the memory. In analogy, what are needed for a singular value for the pointer in typelist are the following: first, it is a legal typelist value, which means that itself has to be a typelist; second, it semantically means there is no node after itself. Obviously, `typelist<null_type, null_type>' satisifies these two requirements much better than `null_type'.
A macro-free typelist generator
Generating a typelist as the example shown above is tedious and error-prone. Easier ways are definitely wanted. In some libraries, such as the famous LOKI, this task relies on the (evil) C macro with ugly interface. We want to do it in a much better way especially without all the hassle of C macros. More specifically, the challege is to implement the most clean and easy-to-use generator with an interface like:
typedef gen_typelist<T0, T1, T2, T3>::type tl0;
// tl0 == typelist<T0, <typelist<T1, typelist<T2, typelist<T3, null_typelist> > > > >
typedef gen_typelist<T0, T1>::type tl1;
// tl1 == typelist<T0, <typelist<T1, null_typelist> > >
This challenge comes with two problems to be solved: First, how to let the `gen_typelist' accept variable number of template arguments? Second, how to get the wanted typelist?
The C++ language supports default values for template parameters. Employing this, we can make a template to behave as if it can accept variable number of template arguments. For example,
template <typename T0, typename T1 = null_type, typename T2 = null_type>
struct gen_typelist
{
};
typedef gen_typelist<int> t1; // OK.
typedef gen_typelist<int, bool> t2; // OK.
typedef gen_typelist<int, bool, char> v3; // OK
This language feature can really be used to solve the first problem. Of course, there is an upper bound for the number of template arguments, but it is not a big problem if the template has a large number of parameters.
Now we get all the types for constructing the typelist in `gen_typelist'. The least thing we can do is to construct a typelist from the given types in a bruteforce way. To continue the above `gen_typelist' example, we get:
template <typename T0, typename T1 = null_type, typename T2 = null_type>
struct gen_typelist
{
private:
typedef typelist<T0, typelist<T1, typelist<T2, null_typelist> > > crude_tl_;
public:
};
This typelist is crude in the way that some `null_type' are possibly included. Next, we need to further refine it to remove all `null_type' except for the `null_typelist'. To do this, we process `crude_tl_' with a meta-program defined as follows:
template <typename T0, typename T1 = null_type, typename T2 = null_type>
struct gen_typelist
{
private:
typedef typelist<T0, typelist<T1, typelist<T2, null_typelist> > > crude_tl_;
template <typename T, typename L, int DUMMY = 0>
struct refine1_
{
typedef typelist<T, L> type;
};
template <int DUMMY>
struct refine1_<null_type, null_typelist, DUMMY>
{
typedef null_typelist type;
};
template <typename TL, int DUMMY = 0>
struct refine_
{
typedef typename refine1_<typename TL::type, typename refine_<typename TL::sublist>::type>::type type;
};
template <int DUMMY>
struct refine_<typelist<null_type, null_typelist>, DUMMY>
{
typedef null_typelist type;
};
public:
typedef typename refine_<crude_tl_>::type type;
};
typedef gen_typelist<int, int>::type t2; // t2 is `typelist<int, typelist<int> >'.
The magic is within the inner classes `refine_' and `refine1_'. How they acheive the functionality is an interesting problem left for the readers. :-)
Another way for refining the `crude_tl_' is using a recursive method, as follows:
template <typename T0, typename T1 = null_type, typename T2 = null_type>
struct gen_typelist
{
typedef typelist<T0, gen_typelist<T1, T2> > type;
};
template < >
struct gen_typelist<null_type, null_type, null_type>
{
typedef null_typelist type;
};
The specialization is for terminating the recursion.
Now, we have the facility for easy generation of typelist and can go ahead to have some fun in meta-programing. Before we go, some meta-functions for manipulating typelists are needed. I will show those in the next installment.