From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 8DFB2BC0B for ; Tue, 26 Dec 2006 19:35:59 +0100 (CET) Received: from furbychan.cocan.org (furbychan.cocan.org [80.68.91.176]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id kBQIZwAQ029666 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 26 Dec 2006 19:35:59 +0100 Received: from rich by furbychan.cocan.org with local (Exim 3.35 #1 (Debian)) id 1GzH9Q-0007eS-00; Tue, 26 Dec 2006 18:35:48 +0000 Date: Tue, 26 Dec 2006 18:35:48 +0000 To: micha Cc: OCaml Mailing List Subject: Re: [Caml-list] allocating memory for c-structures Message-ID: <20061226183547.GA29273@furbychan.cocan.org> References: <459166C7.4080005@fantasymail.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <459166C7.4080005@fantasymail.de> User-Agent: Mutt/1.5.9i From: Richard Jones X-Miltered: at concorde with ID 45916B8E.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; allocating:01 0100,:01 malloc:01 interfacing:01 lib:01 malloc:01 pointers:01 pointers:01 avoided:01 ocaml:01 ocaml:01 marshalling:01 marshalling:01 26,:98 blog:98 On Tue, Dec 26, 2006 at 07:15:35PM +0100, micha wrote: > Normaly I allocate memory for c-structures with malloc or with "new" for > c++ objects. Some time ago a read about a library which places external > structures in strings of the interfacing languages (it was a scheme lib > I think). So instead of using malloc or new I would allocate an > ocaml-string and put the c-structure there. So it will be free by the gc. > That seems o.k. for me, any comments? I'm missing something? That seems like it'll work for "opaque" C objects, but it's a bit of a hack. The immediate issues I can think are: (a) Pointers in the C code which point at the object will not be "counted" by the GC, and so the object may be collected while there are still C pointers around. This is easily avoided in OCaml, but read chapter 18 of the manual carefully. (b) By storing the object as a string you're telling the GC not to examine the inside of the object, eg. looking for pointers inside to other objects. Fine, if you know what you're doing, but OCaml already has a number of established ways to do this - eg. using Abstract or Custom blocks - and these standard ways are not just standard, but offer additional features too. Alternatively you may consider a non-abstract block and deliberately allow the GC to look inside. C and OCaml structures are not actually too different. Actually, while I was writing the above, it struck me that perhaps you're talking about some sort of marshalling system? OCaml supports its own marshalling format, and a rich variety of other external forms of marshalling. Rich. -- Richard Jones, CTO Merjis Ltd. Merjis - web marketing and technology - http://merjis.com Internet Marketing and AdWords courses - http://merjis.com/courses - NEW! Merjis blog - http://blog.merjis.com - NEW!