want to look at [https://hackage.haskell.org/package/hacanon-light hacanon-light]. It is currently unmaintained, but the idea of using

+

[[Template Haskell]] is pretty appealing.

−

[http://www.gccxml.org/HTML/Index.html gcc-xml] might be a good way to get the information needed to do more automatic C++ binding generation.

+

[http://www.gccxml.org/HTML/Index.html gcc-xml] might be a good way to

+

get the information needed to do more automatic C++ binding generation.

(BTW, this was written by JeremyShaw, know as stepcut on irc.freenode.net/#haskell if you have questions).

(BTW, this was written by JeremyShaw, know as stepcut on irc.freenode.net/#haskell if you have questions).

Line 22:

Line 22:

=== Making objects accessible to Haskell ===

=== Making objects accessible to Haskell ===

−

According to [https://www.haskell.org/onlinereport/haskell2010/haskellch8.html#x15-1490008 the Foreign Function Interface section of the Haskell 2010 report] -- you import a C++ function by simply specifying the calling convention cplusplus. Unfortunately, no haskell compiler actually supports this calling convention, so we have to use the C calling convention instead.

The standard method for dealing with this is to write C++ code that uses extern "C" to export the methods unmangled. Of course, you still have to uniquify the method names, but *you* get to pick the names instead of letting the compiler do whatever wacky method it wants.

+

The standard method for dealing with this is to write C++ code that

+

uses extern "C" to export the methods unmangled. Of course, you still

+

have to uniquify the method names, but *you* get to pick the names

+

instead of letting the compiler do whatever wacky method it wants.

−

The method presented on this page does not use that method -- it just calls the mangled names directly. So far this seems to work OK...

+

The method presented on this page does not use that method &mdash; it

+

just calls the mangled names directly. So far this seems to work OK...

==== Finding the mangled name ====

==== Finding the mangled name ====

−

C++ allows you to have many methods with the same name, but different arguments. However, the underlying linker does not &mdash;

+

C++ allows you to have many methods with the same name, but different

−

soC++ mangles the methodsnamestoensurethateachmethod name is unique. To import these methods into Haskell,we

+

arguments.However, the underlyinglinkerdoesnot&mdash;soC++

−

need to know the mangledname.Sincethereisnostandardformanglingnames, we must figured out how ourC++compiler

+

mangles the methodsnamestoensurethateachmethodnameisunique.To

−

decides to dothings.

+

import these methods into Haskell, we need to knowthe mangled name.

+

Since there is no standard for mangling names, we must figure out how

+

our C++ compiler decides to do things.

Let's say I want to import the constructor

Let's say I want to import the constructor

Line 74:

Line 79:

==== Importing the method into Haskell ====

==== Importing the method into Haskell ====

−

I then import that into haskell like this:

+

I then import that into Haskell like this:

<haskell>

<haskell>

Line 82:

Line 87:

</haskell>

</haskell>

−

'kapplication_KApplication' is what I want to call this method in haskell-- I can name it anything I want,

+

'kapplication_KApplication' is what I want to call this method in Haskell&mdash; I can name it anything I want,

−

as long as it is a valid haskell identifier.

+

as long as it is a valid Haskell identifier.

C does not have a bool type, so I guessed (and it seems to work) that a C++ bool is just a CInt.

C does not have a bool type, so I guessed (and it seems to work) that a C++ bool is just a CInt.

Line 94:

Line 99:

</pre>

</pre>

−

All the methods in the KApplication class take a pointer to KApplication as their first argument. Normally C++ manages

+

All the methods in the KApplication class take a pointer to

−

thisforyou--so you never see it. Thepointeris,ofcourse,the'this' pointer.

+

KApplicationastheirfirstargument. NormallyC++managesthisforyou

+

&mdash; so you never see it. The pointer is, of course, the 'this'

+

pointer.

==== Calculating the object size ====

==== Calculating the object size ====

Line 136:

Line 141:

=== How to link the program ===

=== How to link the program ===

−

Most programming languages, especially Haskell and C++, link by calling the system linker, passing it appropriate libraries. If you link Haskell and C++ code into the same binary, you cannot have this convenience for both languages. Also, one of both runtime systems may not get initialized correctly.

+

Most programming languages, especially Haskell and C++, link by calling

+

the system linker, passing it appropriate libraries. If you link

+

Haskell and C++ code into the same binary, you cannot have this

+

convenience for both languages. Also, one of both runtime systems may

+

not get initialized correctly.

Currently, I'm using Ghc to do the linking, and instruct it to link the c++ runtime library:

Currently, I'm using Ghc to do the linking, and instruct it to link the c++ runtime library:

Line 145:

Line 154:

</pre>

</pre>

−

This seems to work (with GHC 6.4.1 and G++ 3.3.5). However, I'm pretty certain, the C++ runtime doesn't get initialized, so as soon as someone touches, say {{{std::cin}}}, all hell breaks lose. I dare not think about what happens, should I ever feel the need to bring a third language into the mix.

+

This seems to work (with GHC 6.4.1 and G++ 3.3.5). However, I'm pretty

+

certain, the C++ runtime doesn't get initialized, so as soon as someone

+

touches, say {{{std::cin}}}, all hell breaks lose. I dare not think

+

about what happens, should I ever feel the need to bring a third

+

language into the mix.

−

AnswerMe: Can anyone confirm that this works, whether it is supposed to work and how to do this correctly? -- UdoStenzel

+

AnswerMe: Can anyone confirm that this works, whether it is supposed to

Abstract

This page describes some of the black magic needed to call C++ from
Haskell (on Linux, compiled with g++). I refer to it as the "The Hard
Way" because it is a tedious, hand done method of generating C++
bindings. The information on this page is pretty spotty and probably
wrong in places. But hopefully it will be of some use. You may also
want to look at hacanon-light. It is currently unmaintained, but the idea of using
Template Haskell is pretty appealing.

gcc-xml might be a good way to
get the information needed to do more automatic C++ binding generation.

(BTW, this was written by JeremyShaw, know as stepcut on irc.freenode.net/#haskell if you have questions).

The standard method for dealing with this is to write C++ code that
uses extern "C" to export the methods unmangled. Of course, you still
have to uniquify the method names, but *you* get to pick the names
instead of letting the compiler do whatever wacky method it wants.

The method presented on this page does not use that method — it
just calls the mangled names directly. So far this seems to work OK...

Finding the mangled name

C++ allows you to have many methods with the same name, but different
arguments. However, the underlying linker does not — so C++
mangles the methods names to ensure that each method name is unique. To
import these methods into Haskell, we need to know the mangled name.
Since there is no standard for mangling names, we must figure out how
our C++ compiler decides to do things.

All the methods in the KApplication class take a pointer to
KApplication as their first argument. Normally C++ manages this for you
— so you never see it. The pointer is, of course, the 'this'
pointer.

Calculating the object size

We also need to know how big the object is, so we can allocate space for it with new() later.

How to link the program

Most programming languages, especially Haskell and C++, link by calling
the system linker, passing it appropriate libraries. If you link
Haskell and C++ code into the same binary, you cannot have this
convenience for both languages. Also, one of both runtime systems may
not get initialized correctly.

Currently, I'm using Ghc to do the linking, and instruct it to link the c++ runtime library:

This seems to work (with GHC 6.4.1 and G++ 3.3.5). However, I'm pretty
certain, the C++ runtime doesn't get initialized, so as soon as someone
touches, say {{{std::cin}}}, all hell breaks lose. I dare not think
about what happens, should I ever feel the need to bring a third
language into the mix.

AnswerMe: Can anyone confirm that this works, whether it is supposed to
work and how to do this correctly? — UdoStenzel

An example

Here is an example where I create enough bindings to launch a small KDE app.
This is actually a bad example because it has a lot of stuff that is unrelated to C++ bindings.
Also, it does some things wrong. Things I know of include:

* Should probably use Finalizers and ForeignPtr's
* I read somewhere that you need to call the C++ main() to ensure that some C++ stdlib stuff is properly initialized.

Also of note is the ->> operator. The entire purpose of the operator is to make things look more C++ like.

instead of writing:

kapplication_KApplicationkapp11

I can use the more C++ like syntax:

(kapp->>kapplication_KApplication)11

Though, I think I actually prefer the former.

To compile the code on a Debian system you need:

ghc6 and the kdelibs4-dev

My kdelibs is version 3.3.2 and was compiled with the g++ 3.x compiler.
I think the name mangling scheme changed with g++ 4.0, so if you are using that version
you will have to figure out the new mangled names.

Also, I don't believe the buttons are actually hooked up yet. I think it just sits there looking pretty.