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 TAA16888; Fri, 4 Apr 2003 19:14:09 +0200 (MET DST) 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 TAA15698 for ; Fri, 4 Apr 2003 19:14:08 +0200 (MET DST) Received: from mail.exomi.com (mail.exomi.com [217.169.64.72]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h34HE7921870 for ; Fri, 4 Apr 2003 19:14:07 +0200 (MET DST) Received: from exomi.com (unknown [10.0.5.5]) by mail.exomi.com (Postfix) with ESMTP id 9FB915DFE; Fri, 4 Apr 2003 20:14:06 +0300 (EEST) Date: Fri, 4 Apr 2003 20:14:05 +0300 Subject: Re: [Caml-list] Bug? Printf, %X and negative numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: Brian Hurt From: Ville-Pertti Keinonen In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam: no; 0.00; caml-list:01 bug:01 printf:01 bloat:01 foo:01 inlining:01 inlined:01 callback:01 unboxed:01 pointers:01 model:01 mli:01 ints:01 ocaml:01 int:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > One of the things I dislike about C++ template is code bloat. This is > the > undiscussed cost of templates. So you make a template foo. You ... Specializations aren't the only reason C++ templates cause significant code growth. Another is that they (in the case of the most commonly used HP/SGI STL, at least) use inlining very heavily, so each instantiation is big and a lot of inlined code is instantiated several times all over the place. For some cases, inlined handling of data structures is good. Consider the performance of the STL sort vs. anything based on a callback or virtual method. I'm not a big fan of C++ templates, but I don't think they're a very good argument against all specialization. > And this applies to Ocaml even more so. I mean, consider the function: Less so, I would think, since most types are compatible. > let f x = ... > > OK, so to specialize it for unboxed ints vr.s pointers takes two > implementations of the function, f_pointer and f_int, right? So now > consider the function: > > let f x y z w = ... > > Do we need 16 different specializations for this function? Not if they're generated at the point where they are first used(*), in which case a maximum of 16 specializations are created - compared to C++, where there is no maximum, and you often end up having things like std::map and std::map which are in fact identical. (*) Obviously this requires some adjustments to the compilation model. A quick grepping through .mli files in the OCaml source distribution reveals that there are zero instances of the string 'd but quite a few instances of 'c, which would seem to indicate that four variables is not common. ------------------- 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