From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 8FC5CBC37 for ; Mon, 8 Feb 2010 18:58:21 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcCAP7eb0vRVd7Iimdsb2JhbACTOYdLPAEBAQoJDAcRBa8UhDqIcQEBAwWETwSJXIIi X-IronPort-AV: E=Sophos;i="4.49,431,1262559600"; d="scan'208";a="56332281" Received: from mail-pz0-f200.google.com ([209.85.222.200]) by mail4-smtp-sop.national.inria.fr with ESMTP; 08 Feb 2010 18:58:20 +0100 Received: by pzk38 with SMTP id 38so7664140pzk.9 for ; Mon, 08 Feb 2010 09:58:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=QZwyOtHV0Pt9KdYOKyjtJOucEsoZ312Iqfw6zhtTfR0=; b=qT0mRAisZFmTnrjyqR3DSfpebAMmS7OxtlfHcyn4Gu3PnUqBEXT/rjlm2B6l6+wI7Z UznBXSHkoKe+yPRrvj1xVu2kRI16WrSUlm1W1imP9j0gh6Hjd7l11XyaQuyv/asCMB8a zrsG4OE17KRZ9r6k8dwjcIXdb9r5mMrVsVLcI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=FPM7So+t6VT/zwbb25JlMV0lUaM9wC2dgwVb41cKCbH2sgBQOVkqDc6JYOU1kfnYTd JkNQe3ZRwYOc9bTfDbawscOXgmr/g2t7oS+H63BhbWw5RU43aMlI6ehxwPtH+Aj/EWSh EQA4rDTmUBbsdt24788v3q324lRazg1IdhS4o= MIME-Version: 1.0 Sender: luca.de.alfaro@gmail.com Received: by 10.140.180.20 with SMTP id c20mr1519613rvf.12.1265651899196; Mon, 08 Feb 2010 09:58:19 -0800 (PST) In-Reply-To: <4B704D68.4000404@citycable.ch> References: <28fa90931002071813k7330ad34s7a2ec8b4cf1c3d11@mail.gmail.com> <7b0bd61a1002080803n6cda4bc5g9eeb8d559538598f@mail.gmail.com> <28fa90931002080833y2ca71705q319a3193d3e75d9f@mail.gmail.com> <4B704D68.4000404@citycable.ch> From: Luca de Alfaro Date: Mon, 8 Feb 2010 09:57:59 -0800 X-Google-Sender-Auth: 400e236fe7f1dc4f Message-ID: <7b0bd61a1002080957u31ec557bha59fd1d38995ebe3@mail.gmail.com> Subject: Re: [Caml-list] Re: How to wrap around C++? To: guillaume.yziquel@citycable.ch Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=000e0cd1a734dc685a047f1a8b69 X-Spam: no; 0.00; guillaume:01 ocaml:01 nonstandard:01 guillaume:01 ocaml:01 bindings:01 bindings:01 arrays:01 arrays:01 structs:01 alloc:01 val:01 val:01 bigarrays:01 swig:01 --000e0cd1a734dc685a047f1a8b69 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you Guillaume. The reason why it is complex for me to use C/C++ inside Ocaml is that it is a huge, and hugely complex, body of C/C++ code, that comes with all sort of nonstandard things, and with its own entire build process. It is not clear to me what happens if the main file is not some very special setup that C/C++ is using. I will look into it, but the difficulty is determined by the conventions and build process of the C/C++ I have to deal with. Luca On Mon, Feb 8, 2010 at 9:44 AM, Guillaume Yziquel < guillaume.yziquel@citycable.ch> wrote: > Luca de Alfaro a =E9crit : > >> I am trying another approach... it might make more sense for me to embed >> the >> Ocaml into C++. >> > > This is not the way you'll get the most help out of this list. People are > more familiar with making C bindings. Making C++ bindings is rather close= to > it. > > > I have read the instructions, and it seems feasible, except that I have = a >> few questions: >> >> - All I need to pass, as arguments, are int, float, string, and arrays >> of >> these. Any example of how to deal with the arrays? >> > > You need to construct them from C side, and it's more a pain than taking = C > structs and wrapping them into OCaml. > > The manual describes the structure of OCaml values rather precisely. Ther= e > are also some pages by Richard Jones on his blog which explain rather nic= ely > the internals of OCaml values. One advice: stick to the macros provided. = Do > not try to construct manually, say, OCaml strings on the C side. Use > caml_copy_string and friends. > > - How can I return arrays, in a way that C or C++ understands? How ca= n >> I >> >> return tuples, i.e., how can I return multiple values from Ocaml to C? >> > > These are documented in the manual and in Richard Jones' blog. > > For couples, you can do > > value couple =3D caml_alloc(2, 0); >> Store_field(couple, 0, my_ocaml_val); >> Store_field(couple, 1, my_other_ocml_val); >> > > For arrays, you'll have seamless integration by using Bigarrays. > > - Finally, do I need to worry about the Ocaml garbage collector, if I >> >> call Ocaml from C/C++? Will it run every now and then? How can the >> garbage >> collector know whether a value returned by an Ocaml function is still >> being >> used in C/C++? How can I tell it that it is no longer used? >> > > Essentially, the garbage collector will run potentially each time you > allocate an OCaml value. caml_copy_string? the GC may run. > > You have to register values being used on the C side as a GC root. It's > easier and more documented to do it the other way round by calling C++ fr= om > OCaml. > > > The problem I am trying to solve seems to be a can of worms from whichev= er >> angle I take it... >> > > No. > > The solution I proposed with Swig is very verbose, but it is a clean > solution if you do it manually. > > You have Makefile compilation instructions to compile C++ with OCaml (the > main issue with C++ and the extern "C" is essentially the name mangling o= f > symbols provided by your C++ object files. All the rest is pretty similar= to > C. This is really the *main* point). > > You have at the end of my last email and example of how to construct an > object and feed it back to OCaml. It may not be really clean, it lacks > finalisers, but these last two points are stuff that you're going to have= to > deal with anyway if you're going with the OCaml/C interface. Look up "cus= tom > blocks" and finalisation in the OCaml manual section concerning the C > interface. > > Luca >> > > All the best, > > > -- > Guillaume Yziquel > http://yziquel.homelinux.org/ > > --000e0cd1a734dc685a047f1a8b69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you Guillaume.=A0
The reason why it is complex for me to use C/C+= + inside Ocaml is that it is a huge, and hugely complex, body of C/C++ code= , that comes with all sort of nonstandard things, and with its own entire b= uild process. =A0It is not clear to me what happens if the main file is not= some very special setup that C/C++ is using. =A0I will look into it, but t= he difficulty is determined by the conventions and build process of the C/C= ++ I have to deal with.=A0

Luca

On Mon, Feb 8, 2= 010 at 9:44 AM, Guillaume Yziquel <guillaume.yziquel@citycable.ch> wrote:
Luca de Alfaro a =E9crit = :
I am trying another approach... it might make more sense for me to embed th= e
Ocaml into C++.

This is not the way you'll get the most help out of this list. People a= re more familiar with making C bindings. Making C++ bindings is rather clos= e to it.


I have read the instructions, and it seems feasible, except that I have a few questions:

=A0 - All I need to pass, as arguments, are int, float, string, and arrays= of
=A0 these. =A0Any example of how to deal with the arrays?

You need to construct them from C side, and it's more a pain than takin= g C structs and wrapping them into OCaml.

The manual describes the structure of OCaml values rather precisely. There = are also some pages by Richard Jones on his blog which explain rather nicel= y the internals of OCaml values. One advice: stick to the macros provided. = Do not try to construct manually, say, OCaml strings on the C side. Use cam= l_copy_string and friends.

=A0 - How can I return arrays, in a way that C or C++ understands? =A0How = can I

=A0 return tuples, i.e., how can I return multiple values from Ocaml to C?=

These are documented in the manual and in Richard Jones' blog.

For couples, you can do

value couple =3D caml_alloc(2, 0);
Store_field(couple, 0, my_ocaml_val);
Store_field(couple, 1, my_other_ocml_val);

For arrays, you'll have seamless integration by using Bigarrays.

=A0 - Finally, do I need to worry about the Ocaml garbage collector, if I<= div class=3D"im">
=A0 call Ocaml from C/C++? =A0Will it run every now and then? How can the = garbage
=A0 collector know whether a value returned by an Ocaml function is still = being
=A0 used in C/C++? =A0How can I tell it that it is no longer used?

Essentially, the garbage collector will run potentially each time you alloc= ate an OCaml value. caml_copy_string? the GC may run.

You have to register values being used on the C side as a GC root. It's= easier and more documented to do it the other way round by calling C++ fro= m OCaml.


The problem I am trying to solve seems to be a can of worms from whichever<= br> angle I take it...

No.

The solution I proposed with Swig is very verbose, but it is a clean soluti= on if you do it manually.

You have Makefile compilation instructions to compile C++ with OCaml (the m= ain issue with C++ and the extern "C" is essentially the name man= gling of symbols provided by your C++ object files. All the rest is pretty = similar to C. This is really the *main* point).

You have at the end of my last email and example of how to construct an obj= ect and feed it back to OCaml. It may not be really clean, it lacks finalis= ers, but these last two points are stuff that you're going to have to d= eal with anyway if you're going with the OCaml/C interface. Look up &qu= ot;custom blocks" and finalisation in the OCaml manual section concern= ing the C interface.

Luca

All the best,


--
=A0 =A0 Guillaume Yziquel
http://yziquel.= homelinux.org/


--000e0cd1a734dc685a047f1a8b69--