GHC and C++

[Simon Peyton-Jones]

Daan, Kevin, (and Mike, Sarah?)

You two/three seem to be the de-facto experts when it comes to building
DLLs with GHC and linking them to C++ DLLs.  Would either of you like to
write up some stand-alone notes that explain how to do it, and what the
pitfalls are?  You can make suggestions for improving GHC too!

What otherwise happens is that everyone has to reinvent the wheel.  And,
to be honest, we're not well up on this at GHC home base, so you could
do a far better job than we could.

The important thing is to explain enough context that someone does not
have to be a total Win 32 expert to understand what's going on.  Claus's
recent message explaining about Cygwin paths was an excellent example of
how to do it.

It'd be a real service.

Simon



| -----Original Message-----
| From: Daan Leijen [mailto:daanleijen@xs4all.nl]
| Sent: 02 February 2003 22:34
| To: Nick Name; gui@haskell.org
| Subject: Re: [GUI] ByeDemo
|=20
| > >  I have been thinkering with the wxWindows library
| > >  and made a small Haskell binding to it that just supports this
| > >  example. It was an interesting exercise since the wxWindows
library
| > >  is a large object-oriented C++ library. (but very portable, well
| > >  supported, efficient and with lots of super widgets, like an
openGL
| > >  canvas and a HTML renderer)
| >
| > It is really interesting. How did you bind the library? Could you
make a
| > tarball of the binding, the example and a makefile? It could be used
as
| > an "Haskell->C++" tutorial.
|=20
| (warning: rather detailed and long answer...)
|=20
| I have only done it for windows yet, both with mingw32 and visual C++.
| Funny thing: the final (stripped) DLL with mingw32 was 2.8mb, while
the
| visual C++ DLL (with the same functionality) was just 640kb :-).
|=20
| In the end, I couldn't link it directly with a haskell application due
to the
| difference between the C++ and plain C runtimes, so I have made
dynamic
| link library (.dll) of the C++ code. This code exposes a plain C
interface (with "extern
| "C"").
| This interface is basically a flat C view on the object oriented
wxWindows library.
|=20
| This DLL is accessed with foreign imports from Haskell. Call backs are
dynamically
| created using dynamic exports ("wrapper"). Actually, the hardest part
was to
| make sure that the resource files (.rc) were properly linked in the
DLL, as we don't
| want to deal with those from Haskell.
|=20
| I don't know yet if this approach also works for unix's (.so files?)
or MacOSX,
| but there probably is a way to do this. In the end, it is good enough
if there is
| some way of wrapping the C++ code into a C library. Maybe someone on
this list
| can tell me more about how this could work on unix like platforms???
|=20
| The part that is most challenging, and which I am still working on, is
trying to fit
| the event model of wxWindows into a reasonable model for Haskell (or
other
| languages for that matter). Somehow, I need to create "universal"
widget objects
| that are programmable from outside (i.e. Haskell) but normally, one
derives
| application
| specific objects for each widget in wxWindows. There are mechanisms
for more
| dynamic
| applications (like I want) but I am still trying to figure out the
right way to do it.
|=20
| I think this is basically a universal problem when trying to interface
to foreign object
| oriented
| (or any other paradigm for that matter) with a functional language. It
is not just the
| marshalling
| and calling conventions, but the programming model makes a huge
difference. Years
| ago, when
| designing H/Direct we automated the marshalling process, but it seems
that that is
| just a small
| part of the problem. Trying to fit into an entirely different
programming model is very
| hard. For
| an extreme example, I think that there is no reasonable way of
interfacing to the Java
| Swing model.
|=20
| Fortunately, it seems that the wxWindows library is much more
flexible, and up till
| now, I haven't
| encountered any hard problems. Maybe this is actually the right way to
go for a
| Haskell GUI library
| -- let others do the hard work of maintaining a rich,portable gui
library, and we  just
| have to do
| the hard work of interfacing to c++ once.
|=20
| All the best,
|     Daan.
|=20
|=20
| > Vincenzo
| >
| > --
| > First they ignore you, then they laugh at you,
| > then they fight you, then you win.
| > [Gandhi]
| >
| > _______________________________________________
| > GUI mailing list
| > GUI@haskell.org
| > http://www.haskell.org/mailman/listinfo/gui
| >
| >
|=20
|=20
| _______________________________________________
| GUI mailing list
| GUI@haskell.org
| http://www.haskell.org/mailman/listinfo/gui