Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] partial eval question
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: William Chesters <williamc@p...>
Subject: Re: [Caml-list] partial eval question
Andrew Lenharth writes:
 > And that's an improvement over
 > 
 > template <int N>
 > inline double pow (double x) {
 >   return x * pow<N-1>(x);
 > }
 > template<>
 > inline double pow<0> (double x) {
 >   return 1.0;
 > }
 > 
 > in what way exactly?

What I wrote, the "obvious thing", is

   -- easy to write, and hard to get wrong

   -- gives much less confusing error messages if you get it slightly
wrong

   -- easy to read

   -- uses a smaller subset of the language, so is especially easier
for non-C++ experts

   -- more general, in that it doesn't blow up and use silly amounts
of space (and probably more time too, given cache churn) if N is not
tiny

   -- more general also in that the same code does both the
general-purpose (n known only at runtime) and the special-purpose
job

 > The C example relies on a fairly smart compiler to 
 > do interprocedual analysis.

Depends what you mean by fairly smart.  This is standard stuff: gcc is
really not the best optimising compiler around.

 > The C++ example only requires the inline keywork be honored, and
 > you don't need explicit pow3 pow2, you have pow<3> pow<2> pow<any
 > constant>.
 > 
 > Gives a bit more control over code generation.

It does.  I personally feel (actually have learned the hard way) that
using C++ templates for multi-stage programming is mostly much more
trouble than it is worth---especially when you realise what careful
exploitation of C-level specalisation by inlining can do.

If you really want more control over code generation (not forgetting
that just writing out what you want by hand is often the simplest
option in practice!) then I think C++ templates are a dead end---far
better to make the object language the same as the target language,
as in MetaOcaml and similar.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners