Introduction
My last three columns were an introduction to C++ template metaprogramming. Naturally, all my examples were simplified in one way or another. In fact, I pointed out several times that you should not use any of my examples verbatim. For each and every one of them, there was a better and more mature version to be found in the Boost library [1]. That's all very well, because simplified examples are an important part of any introductory exposition. However, no introduction is complete without at least one example that is representative of real-life situations. Therefore, I found myself confronted with the daunting task of coming up with an application of C++ metaprogramming that fits into one column, can be considered of real interest rather than just a toy application, and is not already in the Boost library [1] or in Andrei Alexandrescu's book [2]. I think I found something. Well, almost. What I will present to you here is a slightly simplified version of my solution to the problem. The real solution is available for download at <www.cuj.com/code>.
Better Default Function Arguments
As we all know, C++ allows us to specify default values for function parameters. However, if we specify a default value for one parameter, then we must do the same for all remaining parameters. Moreover, if a caller wishes to use the default value for a particular parameter, then she necessarily gets the default values for all remaining parameters. I guess everybody has been in a situation where it would have been convenient to have default function arguments without these restrictions. In this imaginary C++, it would be possible to declare a function like this:
class X; void Foo(int i=42, const X&, int j=43);A caller could then select the default value for any parameter that specifies a default, using the imaginary default keyword, like this:
X anX; Foo(default, anX, 43);I remember several people mentioning casually that this kind of default function argument specification can be "faked" with C++ metaprogramming. However, I have never seen an actual implementation. Therefore, this will be my real-life application of metaprogramming techniques. To be honest, I should say that there is probably a reason why I have never seen this implemented before: the whole thing works nicely, but it is not exactly painless to use. You have to really want these generalized default arguments before you would actually use this. But then, it all depends.
The General Idea
Since we do not have the aforementioned default keyword in real C++, we must come up with something else that the caller of a function can put where the default argument is desired. The solution is to use a dummy argument of a special type whose sole purpose is to indicate the use of the default argument. With this idea, we can take a shot at some pseudocode for the function Foo described above.
class default_parameter_tag{};
template<
typename ArgType1,
typename ArgType3>
void Foo(ArgType1 arg1,
const X& arg2, ArgType3 arg3)
{
int arg1_processed;
if(ArgType1 converts to int)
arg1_processed = arg1;
else if(ArgType1 ==
default_parameter_tag)
arg1_processed = 42;
else
assert(false);
// similarly for arg3
// ...
}
The selection of the correct if branch should of course happen at compile time, and the assert should be a compile error. Conceptually, this is exactly how our implementation will work: the types of the arguments for which there are default values will be template parameters. When the client passes a dummy object of type default_parameter_tag as an argument, our mechanism will use that type information to detect that the default value should be used for the respective function argument.
There is just one more thing to consider before we can tackle the implementation: in order to get a generic solution that works smoothly for any number of function parameters and every possible combination of default values, we must package the function arguments into some sort of structure that can be generated at compile time. In my last column, I showed you exactly this kind of structure as an application of typelists. I also mentioned that Boost has a much more mature implementation of the same idea, namely Jaakko Järvi's tuple class [3]. Basically, this is what we want to use here. However, in order to incorporate the default argument processing seamlessly into the tuple manipulation, I have written my own tuple class for this special purpose.
The Implementation
Listing 1 shows the definition of a class named parameter_tuple. It is a tuple class that is tailored to work for the purpose of generalized default function arguments. Notice how the code makes ample use of Boost's MetaC++ functions such as add_reference. Let me first remind you how tuples work. Conceptually, a tuple is a plain old struct with get and set methods. Technically, tuples use a nested structure to hold their data. A tuple has two member variables. The first one is the first data member. The second one is another tuple that holds the remaining data members, using the same nested structure. A good way to visualize a tuple is as a set of Russian dolls, where each doll holds a penny and another doll. In my last column, I used a simple tuple class as an example for the application of typelists. I also mentioned that it is possible to write a tuple class without the explicit use of typelists. This is because the nested structure of tuples mirrors the nested structure of typelists. Therefore, the underlying typelist of a tuple (namely, the list of types of the tuple's data members) can be incorporated into the tuple class itself. This is what I have done here. The MetaC++ function nth_parameter_type in Listing 1 demonstrates this: it retrieves the type of the nth element of a tuple (i.e., the nth type on the typelist that is implicitly contained in the tuple). If you ignore the various constructors of the class parameter_tuple for now, you won't find it difficult to understand how it is just a simple tuple class.
Let us now look at how the class parameter_tuple is used to provide us with generalized function parameters. To this end, we'll use the function Foo that we declared earlier in imaginary C++ like this:
class X; void Foo(int i=42, const X&, int j=43);To really get the intended default arguments, we now declare Foo like this:
template<typename ParameterTuple> void Foo(const ParameterTuple& args);In fact, any function that wishes to use our generalized default parameters must be declared exactly like this. Therefore, it is necessary to document the actual, intended types of the parameters with the declaration. The best way to do this is to provide a typedef for the correct type of parameter_tuple.
typedef make_parameter_tuple_type< int, const X&, int >::ret FooParams;Listing 1 has the definition of the MetaC++ function make_parameter_tuple_type, which creates an instantiation of the class template parameter_tuple with the indicated element types.
Let us now look at how a client would call the function Foo. If no default values at all are to be used, then the client may use the typedef FooParams to package the arguments:
X anX; Foo(FooParams(52, anX, 53));Notice how we are using the first parameter_tuple constructor here, which takes as its arguments the elements that the tuple is to hold. If default values are to be used for some or all of the parameters that allow default values, then dummy objects of type default_parameter_tag must be passed in the respective locations. For this to be possible, the packaging tuple must have the appropriate type. This type can be obtained by looking at the definition of FooParams and then placing the type default_parameter_tag in each slot where a default value is to be used. For example, the following call to Foo uses the default for the first argument:
typedef make_parameter_tuple_type< default_parameter_tag, const X&, int >::ret FooParamsDefault1; X anX; Foo(FooParamsDefault1( default_parameter_tag(), anX, 53 ) );The typedef FooParamsDefault1 could be provided by the implementer of Foo, or it could be left to the client to figure it out. Either way, it's not exactly as pretty as you might wish. It would of course be much nicer if we could create the parameter_tuple using one of those little make functions that abound in the STL, using function template argument deduction to avoid having to explicitly name the template arguments. However, that would not work here because function template argument deduction would fail to deduce reference types like the const X& in our example.
Now let's look at the implementation of Foo in Listing 2. The first two lines of the function definition introduce the default values for the first and third parameters. To this end, another instantiation of the class template parameter_tuple is introduced via the typedef FooDefaultParams. This instantiation is obtained from the original FooParams by inserting the type mandatory_parameter_tag in each argument slot where no default value will be provided. In the second line of Foo's definition, an object named default_args of type FooDefaultParams is declared and filled with the default values for the respective arguments. Dummy objects of type mandatory_parameter_tag are used where no default values are provided.
The crucial part is the line:
FooParams args
(client_args, default_args);
Here, the final argument tuple for Foo gets constructed, and here is where
a MetaC++ program gets executed to decide at compile time if and when default
values for the arguments are to be used. Look at the definition of parameter_tuple
in Listing 1 and find the constructor from
two parameter_tuple objects. First, notice that the constructor works recursively:
it first constructs the element of the tuple, and then it recursively constructs
the nested tuple. Next, notice that there is a default version of the constructor,
and there is an overload for the case where the element type of the first argument
is default_parameter_tag [4]. Therefore, when the compiler creates the
nested function calls to the constructor from the source line:
FooParams args
(client_args, default_args);
it actually executes a meta-if branching on each nesting level. If the argument that the client has passed in the object client_args is of the type default_parameter_tag, then the second version of the constructor gets called, which means that the default value is used for that argument. Otherwise, the first version of the constructor is called, and the client's argument is used.
At this point in the definition of Foo, the final set of arguments is available in the tuple args. Listing 2 shows a call to an internal helper function FooInternal as the final line. The reason for this is that for each combination of default values and client-supplied values of Foo, Foo's template parameter ParameterTuple has a different value. Therefore, the compiler will instantiate a completely separate version of Foo for each of these combinations. To avoid the code bloat that would result from this, the actual body of Foo should be delegated to the helper FooInternal. In this example, it is clear how the helper function should be declared:
void FooInternal(int, const X&, int);In general, there is an additional subtlety about the helper function. Ideally, the entire default argument mechanism should be set up so that by the time the final function arguments have been put in the parameter_tuple object, only one copy has been made of each argument that is passed by value. The version that I am describing here does not fulfill that requirement: it makes two copies of each value argument, one when the client packages the arguments and another when the implementer creates the tuple containing the final function arguments. The version that you will find on the CUJ website, <www.cuj.com/code>, fixes that, at the cost of making the source code considerably more complex. Either way, if we pass value arguments to the helper function by value again, then another copy will be made. Therefore, the helper function should take all arguments that were originally passed by value as const references, or as plain references if the implementer of the helper function insists on (ab)using value parameters as modifiable local variables.
The version of parameter_tuple that is presented in Listing 1 works for functions with up to four parameters. The places where it needs to be modified to accommodate more parameters are marked in the code with the comment "EXTEND," and it should be clear what the necessary modifications are.
Conclusion
Both the code presented in Listing 1 and the final version available at <www.cuj.com/code> have been compiled and tested with the Metrowerks compiler v4.2.5.766. I would be interested to know how this code fares with other compilers. (I know what the answer is for Microsoft Visual C++.) Also, the whole thing is my first shot at solving the problem of generalized default arguments. I would be interested to know if anybody has any ideas for a solution that is less intrusive and easier to use.
References
[1] <www.boost.org>[2] Andrei Alexandrescu. Modern C++ Design (Addison-Wesley, 2001).
[3] <www.boost.org/libs/tuple/doc/ tuple_users_guide.html>
[4] From the point of view of MetaC++, the second version of the constructor can be viewed as a partial specialization that implements an if branching. Technically, however, it is an overload and not a partial specialization. For a complete discussion of this subject, see: Herb Sutter. "Sutter's Mill: Why Not Specialize Function Templates?" C/C++ Users Journal, July 2001.
About the Author
Thomas Becker works as a senior software engineer for Zephyr Associates, Inc. in Zephyr Cove, Lake Tahoe. He can be reached at [email protected].
