From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2003-02-02 11:23:22
On Sun, 02 Feb 2003 08:35:56 -0500, David Abrahams
<dave_at_[hidden]> wrote:
>> This of course works, but the typedef name is quite "log specific";
>> certainly that's worse than having a generic name available at class
>> scope:
>>
>>
>> template <...>
>> struct static_log2 {
>> typedef ... argument_type; // (*)
>> };
>>
>>
>> As Terje Slettebø noticed in private mail, this is a general problem
>> for any 'compile-time function'.
>
>("metafunction")
Well, the term 'compile-time function' was mine, so if it is an error
it is my fault, not Terje's. Maybe I'm not aligned to the standard
terminology, but to me the prefix meta- means "that refers to
something of its same nature", thus for instance a meta-sentence is a
sentence that talks about sentences, a metarule is a rule about rules
and a metaprogram is a program that generates a program. Since a class
template doesn't generate a function I don't call it a metafunction,
though of course if you intend 'function' in a wider meaning then you
can do that as well.
>> A similar issue, for the run-time counter-part, is solved by
>> std::unary_function and std::binary_function. What should we do for
>> the compile-time case?
>
>I don't think the analogy is a good one. unary_ and binary_function
>just supply the typedefs for /specific/ function argument types.
>
>The compile-time case should be handled by passing types instead of
>numbers. If you need the other interface for convenience or legacy
>reasons you can always write static_log2_c<unsigned long>.
>
>Note that using types can allow you to compute a static log2 of
>extended long values even if the C++ compiler doesn't have them built
>in. One just needs an appropriate wrapper type such as:
>
> template <unsigned long hi, unsigned long lo>
> struct long_long
> {
> typedef long_long type;
> unsigned long hi_value;
> unsigned long lo_value;
> };
>
>and specializations of all of the arithmetic primitive metafunctions
>you'll need to use to operate on it.
Yes, but it's quite overkilling in this case. At a point, you have to
balance the generality with the complexity cost (not to talk, in this
case, about compile times).
>> Note that to use argument_type in the above (*) you have to specify
>> an argument for static_log2, despite the fact that actually the
>> typedef doesn't depend on the value of which you compute the
>> logarithm. Even if you introduce, say, an argument_type<> template,
>> like this:
>>
>> // specialize this as needed
>> template <typename T> struct argument_type;
>>
>> template <static_log2_argument_type x>
>> struct argument_type< log<x> > {
>> typedef static_log2_argument_type type;
>> };
>>
>> you still don't solve the problem of the dummy argument: e.g.
>>
>> argument_type< log<1> > :: type; // why 1?
>>
>> Unfortunately you can't default x to zero in the argument_type
>> specialization above. In fact, in this specific case, you could resort
>> to:
>>
>> template <static_log2_argument_type x = 0>
>> struct log {
>> static const int value = ...;
>> };
>>
>
>You've completely lost me here. I tried to understand it three times,
>and gave up.
Sorry, I should have been clearer. The idea was to use a non-intrusive
way to gather the argument type of a generic unary 'metafunction'. The
template argument_type<>, to be specialized as needed, provided a
uniform interface for that; for instance:
template <typename T>
struct argument_type;
template <>
struct argument_type<MyMetaFunction> {
typedef ... type;
};
For static_log2 you would specialize it as:
template < unsigned long x >
struct argument_type< static_log2<x> > {
typedef unsigned long type;
};
That, however, still requires you to specify a number (whatever it is)
when requiring the argument type:
argument_type < static_log2<16> > :: type
whereas I think the intuitive syntax would be:
argument_type < static_log2<> > :: type
To get the intuitive syntax, you can't use a default value in the
specialization of argument_type, simply because that's illegal. But
you could, if you really strive for it at all costs, use a default
(=0) for static_log2 itself. How ugly (and ad-hoc) that would be is
evident to everyone, so I was just, to say, thinking out loud in the
hope that it could suggest other ideas.
Genny.