From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA06955; Mon, 27 Oct 2003 20:10:12 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA20553 for ; Mon, 27 Oct 2003 20:10:10 +0100 (MET) Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h9RJA9100955 for ; Mon, 27 Oct 2003 20:10:09 +0100 (MET) Received: from host81-128-61-136.in-addr.btopenworld.com ([81.128.61.136] helo=beertje.william.bogus) by tungsten.btinternet.com with esmtp (Exim 3.22 #23) id 1AECkh-0000V6-00; Mon, 27 Oct 2003 19:10:07 +0000 Received: by beertje.william.bogus (Postfix, from userid 501) id A4D2B897E9; Mon, 27 Oct 2003 19:12:59 +0000 (GMT) From: William Chesters MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16285.28219.572454.790216@beertje.william.bogus> Date: Mon, 27 Oct 2003 19:12:59 +0000 To: caml-list@inria.fr Subject: Re: [Caml-list] partial eval question In-Reply-To: <20031027185021.GA1793@vilya.homelinux.net> References: <004a01c39c2b$819db8f0$1fcf2952@Archimedes> <20031027081453.37b9f6ee.Damien.Pous@ens-lyon.fr> <16285.15401.421786.814601@beertje.william.bogus> <20031027185021.GA1793@vilya.homelinux.net> X-Mailer: VM 7.04 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid X-Loop: caml-list@inria.fr X-Spam: no; 0.00; chesters:01 williamc:01 paneris:01 caml-list:01 runtime:01 gcc:01 optimising:01 keywork:01 multi-stage:01 inlining:01 metaocaml:01 compiler:01 compiler:01 int:01 writes:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Andrew Lenharth writes: > And that's an improvement over > > template > inline double pow (double x) { > return x * pow(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 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