|
Boost : |
From: Vesa Karvonen (vesa.karvonen_at_[hidden])
Date: 2001-06-25 14:42:30
on 6/25/01 12:21 AM, Jens Maurer at Jens.Maurer_at_[hidden] wrote:
> David Abrahams wrote:
>>
>> I have often heard it claimed that anything you can do with template
template
>> parameters, you can also do without them, but better. I am not familiar
with
>> the arguments, so I can't evaluate their validity.
>
> The arguments concerning template-template parameters I heard concerned
class
> template parameters only. Here, we're dealing with deduced
template-template
> parameters for functions. Note that any "work-arounds" in this area is
likely
> to prevent template argument deduction.
hmn... Admittedly, I just spotted this, and haven't followed the original
thread - perhaps I should, because quaternions have a number of important
applications in computer graphics and animation.
Anyway, I'm interested in seeing plausible uses of template template
parameters. I think that this subject might be more appropriate for a C++
newsgroup, except that I'm mainly interested in seeing actual use of template
template parameters in existing libraries.
...
At least in template metaprogramming, template template parameters seem to
have limited use and member templates seem much more powerful. The only truly
plausible "use" I know of, is that of adapting a metafunction into a
"metafunction object" (is there a better name for this concept?):
template
< template<class> class fun
>
struct make_fun_obj
{ template
< class T
>
struct code : fun<T>
{
};
};
Metafunction objects, which rely on member templates make it possible to:
- bind parameters (and curry):
template
< class fun_obj
, class p1
>
struct bind_2nd
{ template
< class p0
>
struct code : fun_obj::template code<p0,p1>
{
};
};
- return a metafunction object or store it in a type data structure.
These techniques are quite powerful. For instance, I'm using lists that
contain metafunction objects in a parser/compiler for a list based
configuration DSL. This way it is possible to move more and more metacode into
metaprogramming libraries rather than embedding them into component libraries.
...
One of the problems with the C++ template mechanism, which is a pure
functional language, is that it doesn't support currying. In other words, the
following code is not C++:
template<class p0, class p1>
struct cplusplus_class_taking_two_params;
typedef cplusplus_class_taking_two_params
non_cplusplus_class_taking_two_params;
typedef non_cplusplus_class_taking_two_params<int>
non_cplusplus_class_taking_one_param;
typedef non_cplusplus_class_taking_one_param<long>
a_cplusplus_class;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk