Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
O'Caml / C++ interfacing
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Christopher Jeris <cdjeris@m...>
Subject: O'Caml / C++ interfacing

I have embarked on the project of porting O'Caml to the BeOS (see if you're curious).  The bytecode runtime and compiler
build and run fine under BeOS's POSIX compatibility layer, as does the
standard library (stdlib, not libunix).  What I am trying to do is build
O'Caml bindings for the BeOS native libraries, which are all structured
as C++ classes.  This presents a number of problems.

What I would like a user to be able to do is create, use and derive from
an O'Caml class wherever she would have used a C++ class, i.e., where she
might have written

  BWindow *w = new BWindow(...some construction parameters...);

she can now write

  let w = new bWindow ...some construction parameters...;
  w.init () (* we don't quite have constructors yet *)

My idea is to create a simple "wrapper" class around every system class:

  class ML_BWindow: public BWindow { ... };

and export each of its methods as a C function to deal with the fact that
class methods in C++ are not exported simply:

  void ML_BWindow__Show (ML_BWindow *me) { me->Show(); }

I could then declare the class on the ML side using the C externals as

  class virtual vbWindow () = method show: unit end
  external ml_bWindow__show: vbWindow -> unit = "..."
  class bWindow ... as this =
    inherit vbWindow ()
    method show = ml_bWindow__show this

(I seem to need this two-classes thing to deal with the fact that I can't
declare the external without having a type for it; am I missing something
obvious here?)

So far, so good.  The difficulties arise because the user is not the only
one calling methods of the objects so created.  Many object types, such as
BWindow, need to be prepared to receive messages, i.e., method calls, from
the system at any time.  This raises two problems:

* If an object of a class derived on the ML side receives a method call from
the system, ML_BWindow needs to determine the ML subclass of bWindow to
which the object belongs and execute the ML code (if any) of that method
in the derived class.  I can't see easily how to do this (in fact, in the
"Interfacing with C" portion of the O'Caml manual it is stated that the
object and method tables "cannot easily be exploited from C").

* Many types of objects spawn their own threads under BeOS when they
are created (under the BeOS model, an application is a "team" of
multiple threads running in the same address space).  This seems to
introduce all sorts of horrible difficulties.  What I would like to do
is run lots of interpreter threads on the same garbage-collected heap;
is the threads library adaptable to deal with multiple native threads
(rather than simulating multiple threads on a single OS process)?

I'm sort of new to this whole thing so forgive me if I misinterpreted
something obvious --

Christopher Jeris	University of Chicago Math!