question about how to bind c++ classes to ocaml

question about how to bind c++ classes to ocaml

[micha]

when binding an ocaml class  to a c++ class, what's the preferred
way to access member variables of the c++ class?
One is just to implement the get and set function in ocaml to call
the native get/set functions of the c++ class. That way you allways have
some calls from ocaml to c only to get a value of a c++ object.
Another way would be to add similar member variables to the ocaml class
and everytime the c++ side changes a member it updates the ocaml side
too (through direct access). This way you have an additional binding
(the c++ object knows it's ocaml object), but you can access the member
variables in ocaml through normal ocaml methods.

any comments?

 thanks,
 Michael

Re: [Caml-list] question about how to bind c++ classes to ocaml

[Jacques Garrigue]

From: micha <micha-1@fantasymail.de>

> when binding an ocaml class  to a c++ class, what's the preferred
> way to access member variables of the c++ class?
> One is just to implement the get and set function in ocaml to call
> the native get/set functions of the c++ class. That way you allways have
> some calls from ocaml to c only to get a value of a c++ object.
> Another way would be to add similar member variables to the ocaml class
> and everytime the c++ side changes a member it updates the ocaml side
> too (through direct access). This way you have an additional binding
> (the c++ object knows it's ocaml object), but you can access the member
> variables in ocaml through normal ocaml methods.

I suppose this very much depends on how you intend to use this
binding, but trying to synchronize members between C++ and ocaml seems
a lot of work. The only advantage is faster read access, so this
should only be done if you have to read this member often, and the
cost is significant. There is also the induced cost of calling back
ocaml every time the member is updated.
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.

Jacques Garrigue

Re: [Caml-list] question about how to bind c++ classes to ocaml

[Jonathan Roewen]

> 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.

Is this a special annotation for the external keyword? A quick glance
over the ocaml manual doesn't show up anything.

Jonathan

Re: [Caml-list] question about how to bind c++ classes to ocaml

[Michael Wohlwend]

-------- Original-Nachricht --------
Datum: Mon, 14 Aug 2006 09:20:46 +0900 (JST)
Von: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
An: micha-1@fantasymail.de
Betreff: Re: [Caml-list] question about how to bind c++ classes to ocaml

> 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? :-)

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?

cheers
 Michael

ps: I know there is the gtk binding, but understanding the complete source is... not that easy :-)
-- 


Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Re: [Caml-list] question about how to bind c++ classes to ocaml

[Jacques Garrigue]

From: "Michael Wohlwend" <micha-1@fantasymail.de>

> > 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