Re: [boost] Re: compile-time functions interface

From: David Abrahams (dave_at_[hidden])
Date: 2003-02-03 00:29:19

Gennaro Prota <gennaro_prota_at_[hidden]> writes:

> On Sun, 02 Feb 2003 15:02:23 -0500, David Abrahams
> <dave_at_[hidden]> wrote:
>
> [...]
>>My point is this: the only thing that would make argument_type
>>worthwhile, i.e. the ability to do higher-order functional
>>programming, really requires that metafunctions have a consistent
>>polymorphic interface (i.e. type arguments and results).  So if you
>>really insist that static_log2 will not take a type argument, that's
>>fine, but don't waste your time trying to get argument_type to work.
>>
>>You're not operating in a generic world, because there's no way to
>>generalize the neccessary default argument to arbitrary metafunctions
>>with that form.  You might as well settle for static_log2_arg_type
>>instead.
>
> Yes, your point is very clear and you are undoubtedly right. I've done
> some quick tests with the current implementation of static_log2 and it
> turns out that, even with the most optimistic assumptions, compile
> times increase remarkably as soon as you use a type argument. And
> there are problems with broken compilers as well. Just to clarify it:
> the core of the current implementation is the following template
>
<snip>

> That's of course important for our faithful broken compilers. If I
> understand you correctly, having a type argument requires PTS
> instead.

No.

> Regardless of that consideration, I tried quickly changing the code to
> this:
>

<snip> That isn't the approach I'd take if I cared about the speed of
a type-based version.  But no time to write the answer up this
minute...

> Note that I haven't included any of the pachydermic boost headers, I
> have just defined integral_c myself. Also, note that this is just a
> hacked up implementation and that I operated on the argument only, the
> result is still *not* a type. In other words I have made just a part
> of the changes that are needed, so the timings I will have with this
> are likely to be lower than the "real ones". Well, the attached test
> yielded:
>
> // original version:
>
> $ ./bash_test.sh
>
> real    0m34.672s
> user    0m10.610s
> sys     0m22.601s
>
>
> // new version, with type argument
>
> $ ./bash_test.sh
>
> real    0m39.096s
> user    0m14.970s
> sys     0m22.720s
>
>
> Of course, defining integral_c yourself is not enough because it needs
> compiler workarounds, so in practice you should include the boost
> header. Doing that, timings go to:
>
> $ ./bash_test.sh
>
> real    0m42.624s
> user    0m15.710s
> sys     0m22.921s

I think you obviously missed my point altogether, which was:

If you just care about speed, use the tiny and simple implementation
you have, and give up on introspecting about the argument type of the
metafunction.

If you just care about generality, build an implementation around
types.  Then you don't have introspect about the argument type,
because the metafunction will work for any argument type that fits the
concept requirements for integral arithmetic.

If you care about both speed and generality, provide both of the above
interfaces.  There are of course various ways you can optimize, for
example specializing the second version so that integral_c<T,x> where
T fits in an unsigned long just dispatches to the first one.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution