From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 31744BB83 for ; Mon, 14 Aug 2006 10:45:11 +0200 (CEST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k7E8j8tU016980 for ; Mon, 14 Aug 2006 10:45:10 +0200 Received: from localhost (suiren [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.13.7/8.13.7) with ESMTP id k7E8j3n3001896; Mon, 14 Aug 2006 17:45:04 +0900 (JST) Date: Mon, 14 Aug 2006 17:45:01 +0900 (JST) Message-Id: <20060814.174501.82090269.garrigue@math.nagoya-u.ac.jp> To: micha-1@fantasymail.de Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] question about how to bind c++ classes to ocaml From: Jacques Garrigue In-Reply-To: <20060814071715.183780@gmx.net> References: <20060813224715.0769efc9@localhost> <20060814.092046.03363783.garrigue@math.nagoya-u.ac.jp> <20060814071715.183780@gmx.net> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 44E03815.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 ocaml:01 dependencies:01 lablgtk:01 simulate:01 subtyping:01 gtk:01 labltk:01 subtyping:01 coe:01 labltk:01 cheers:01 abstract:01 caml-list:01 functions:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 From: "Michael Wohlwend" > > Calls from ocaml to C are very cheap. If your access function doesn't > > do any allocation (i.e. never calls the GC), you can even make it > > faster by marking it as "noalloc". Beware many functions do > > allocate, including copy_double or copy_string. > > thanks for pointing this out. The "noalloc"-thing isn't really > described in the docu? :-) I suppose this is because it is a bit tricky. You have to look at all the dependencies to be sure that the function will never trigger the GC, and you might easily get it wrong. > Another question which came up was: you can only declare normal > functions (not methods) as "external", so you have to write a c > function for every c++ member function. Do you rebuild the > inheritance hierachy somehow through the type system (maybe with > those mysterious phantom types?) or just put an ocaml class system > on top of it? My approach in lablgtk was to first use phantom types, ie use parameters in abstract types to simulate subtyping. Then there is a second layer using ocaml objects, but I'm not sure you need it in general. It isonly needed because GTK+ has so many classes that it is difficult to track which function comes from which class. In Labltk for instance, there are only phantom types, and without subtyping (it uses a coercion function "coe" instead). This works well if you have a hierarchy with few layers (only two in labltk) Cheers, Jacques Garrigue