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 RAA15051; Wed, 26 Feb 2003 17:48:18 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA15086 for ; Wed, 26 Feb 2003 17:48:17 +0100 (MET) Received: from inria.fr (macaque.inria.fr [128.93.8.158]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h1QGmGT20527 for ; Wed, 26 Feb 2003 17:48:16 +0100 (MET) Date: Wed, 26 Feb 2003 17:49:43 +0100 Subject: Re: [Caml-list] Questions about the C interface Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Damien Doligez To: caml-list@inria.fr Content-Transfer-Encoding: 7bit In-Reply-To: <878ywkbs5j.fsf@student.uni-tuebingen.de> Message-Id: <4E293B08-49AA-11D7-9963-0003930FCE12@inria.fr> X-Mailer: Apple Mail (2.551) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Thursday, February 13, 2003, at 07:39 AM, Falk Hueffner wrote: > I would like to use C functions to manipulate small binary objects and > Ocaml to manage these objects in data structures. So far, I used > alloc_small(WORDS, Abstract_tag) to allocate them. However, that means > I cannot put them into a Hashtbl, and I cannot compare them. Do I need > "custom blocks" to achieve that? Yes. > I don't really need any fancy > comparison or hash function, plain memcmp and hash would do. So I > would like to save the overhead of one pointer per object and the more > costly calling. Unfortunately, we don't have a tag for uninterpreted binary data. The closest we have is strings, but you'd still lose one word, because of the final NUL byte. > Also, I'm wondering when exactly I need CAMLparam/local. If you want to know *exactly*, then the answer is incredibly complex. > I would think > that if I don't allocate anything in the C function, I don't need to > protect locals. That's true. > Also, I would > think that values that are really ints don't need protection... Also true. > The manual doesn't mention that, though. Taking advantage of all these exceptions is very error-prone, and we don't want to encourage it. > Finally, I wonder why the first parameter to alloc_custom (the ops > block) is not a const pointer? Because we don't believe in the const keyword. It's more trouble than it's worth. -- Damien ------------------- 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