Difference between revisions of "Cxx foreign function interface"

From HaskellWiki
Jump to navigation Jump to search
m (Added link to "Foreign_Function_Interface")
m
 
(13 intermediate revisions by 5 users not shown)
Line 1: Line 1:
  +
[[Category:Development_tools]]
This page outlines the challenges involved in building a foreign function interface (FFI) from Haskell to C++ libraries, references some general background about the FFI, and then describes some solutions to the difficulties of C++.
 
  +
[[Category:FFI]]
  +
[[Category:Pages under construction]]
  +
  +
[To do: link here from other pages?]
  +
 
This page outlines the challenges involved in building a foreign function interface (FFI) from Haskell to C++ libraries, beyond the usual difficulties of FFI, and then describes some (possible) solutions to the difficulties presented by C++.
  +
 
== FFI Background ==
  +
 
Understanding the FFI in general, and with respect to the C programming language in particular, is vital background for anyone wishing to build a Haskell interface to C++. The following pages provide background information:
  +
  +
* [[FFI Introduction]]
  +
* [[Applications and libraries/Interfacing other languages]]
  +
* [[Foreign Function Interface]]
   
 
== Difficulties of Interfacing to C++ ==
 
== Difficulties of Interfacing to C++ ==
Line 7: Line 21:
 
In general, the Haskell FFI apparatus specifies how to call a function
 
In general, the Haskell FFI apparatus specifies how to call a function
 
(not a method) using the "ccall" calling mechanism used for C programs.
 
(not a method) using the "ccall" calling mechanism used for C programs.
The FFI specification [[Definition#Addenda_to_the_report]] mentions, but does not require, an alternative calling mechanism for C++; no Haskell compiler has ever implemented this. Extra complications arise in interfacing to C++ libraries:
+
The [https://www.haskell.org/onlinereport/haskell2010/haskellch8.html#x15-1490008 FFI specification] mentions, but does not require, an alternative calling mechanism for C++; no Haskell compiler has ever implemented this. Extra complications arise in interfacing to C++ libraries:
 
# A C++ program allows overloading, using the same function name with different argument lists. But at the binary level, each different version of the function must have its own name. The C++ compiler "mangles" the function names to differentiate them.
 
# A C++ program allows overloading, using the same function name with different argument lists. But at the binary level, each different version of the function must have its own name. The C++ compiler "mangles" the function names to differentiate them.
 
# A C++ program may have classes with constructors, destructors, and methods. These are, obviously, not quite the same as functions, and have no obvious counterpart in Haskell.
 
# A C++ program may have classes with constructors, destructors, and methods. These are, obviously, not quite the same as functions, and have no obvious counterpart in Haskell.
 
# Inheritance (maybe)
 
# Inheritance (maybe)
 
# Template functions, template classes, etc.
 
# Template functions, template classes, etc.
 
== Background Information ==
 
 
Understanding the FFI in general, and with respect to the C programming language in particular, is vital background for anyone wishing to build a Haskell interface to C++. The following pages provide background information:
 
 
* [[FFI_Introduction]]
 
* [[Applications_and_libraries/Interfacing_other_languages]]
 
* [[Foreign_Function_Interface]]
 
   
 
== Building Interfaces to C++ ==
 
== Building Interfaces to C++ ==
   
* [[IO_inside]] describes how to interface to a C++ library using the "export C" declaration (in C++) which makes it look like a C library. This seems to be the standard technique for briding the gap between Haskell and C++.
+
* [[IO inside]] describes how to interface to a C++ library using the "export C" declaration (in C++) which makes it look like a C library. This seems to be the standard technique for bridging the gap between Haskell and C++.
* [[CPlusPlus_from_Haskell]] describes "the hard way" of interfacing to C++, using the mangled C++ names directly without using "export C". It also suggests the possibility of a more automated approach using gcc-xml.
+
* [[CPlusPlus from Haskell]] describes "the hard way" of interfacing to C++, using the mangled C++ names directly without using "export C". It also suggests the possibility of a more automated approach using gcc-xml.
* [http://darcs.haskell.org/~lemmih/hacanon/ Hacanon] automatically generates an FFI to C++ using [Template_Haskell],, but its author has placed it "on hold" and sees some inherent flaws in using Template Haskell. (See David Himmelstrup, 2006, [http://darcs.haskell.org/~lemmih/aboutMe.html "About Lemmih"], accessed 20 June 2009)
+
* [http://darcs.haskell.org/~lemmih/hacanon/ Hacanon] automatically generates an FFI to C++ using [[Template Haskell]], but its author has placed it "on hold" and sees some inherent flaws in using Template Haskell. (See David Himmelstrup, 2006, [http://darcs.haskell.org/~lemmih/aboutMe.html "About Lemmih"], accessed 20 June 2009)
 
** [http://hackage.haskell.org/package/hacanon-light Hacanon-light] is a reduced form of Hacanon, but with the same problems involving Template Haskell. (See ibid.)
 
** [http://hackage.haskell.org/package/hacanon-light Hacanon-light] is a reduced form of Hacanon, but with the same problems involving Template Haskell. (See ibid.)
** [http://darcs.haskell.org/%7Elemmih/zerothHead Zeroth] fixes the problems of Hacanon and Hacanon-light, but is "on hold". (See ibid.)
+
** [http://hackage.haskell.org/package/zeroth ZeroTH] (zeroth) fixes the problems of Hacanon and Hacanon-light. ZeroTH by itself only removes Template Haskell dependencies from Haskell programs; so, you could use either (Hacanon + ZeroTH) or (Hacanon-light + ZeroTH), but not ZeroTH by itself, to generate C++ bindings.
  +
* [http://ianwookim.org/fficxx fficxx] (“eff fix”; [https://github.com/wavewave/fficxx repository]) is an automatic haskell Foreign Function Interface (FFI) generator to C++.
* The [[HQK]] project reports having developed a small Haskell module, qoo, for accessing object-oriented libraries conveniently.
 
  +
* [http://khumba.net/projects/hoppy/ Hoppy] generates bindings to C++ code from API descriptions written in Haskell, and supports exceptions, (limited) templates, callbacks, and garbage collection. Basic C++ standard library bindings are also included.
  +
* [http://www.swig.org/ SWIG] (Simplified Wrapper and Interface Generator) can be used to connect C and C++ with many languages, such as Python, Tcl, Java, several versions of Lisp, and OCAML), but alas, not Haskell. Or at least not directly. But with [http://hackage.haskell.org/package/MissingPy MissingPy], which provides access to the Python interpreter, it might be possible to do this indirectly: first, make the C++ library accessible to Python (already done, in many cases), then, let your Haskell program use the Python interpreter to make calls into the C++ library. Maybe this is also possible with some other scripting languages.

Latest revision as of 22:55, 11 July 2021


[To do: link here from other pages?]

This page outlines the challenges involved in building a foreign function interface (FFI) from Haskell to C++ libraries, beyond the usual difficulties of FFI, and then describes some (possible) solutions to the difficulties presented by C++.

FFI Background

Understanding the FFI in general, and with respect to the C programming language in particular, is vital background for anyone wishing to build a Haskell interface to C++. The following pages provide background information:

Difficulties of Interfacing to C++

Foreign function interfaces (FFIs) from Haskell to C are well developed, but writing an FFI to a C++ library remains a difficult undertaking. In general, the Haskell FFI apparatus specifies how to call a function (not a method) using the "ccall" calling mechanism used for C programs. The FFI specification mentions, but does not require, an alternative calling mechanism for C++; no Haskell compiler has ever implemented this. Extra complications arise in interfacing to C++ libraries:

  1. A C++ program allows overloading, using the same function name with different argument lists. But at the binary level, each different version of the function must have its own name. The C++ compiler "mangles" the function names to differentiate them.
  2. A C++ program may have classes with constructors, destructors, and methods. These are, obviously, not quite the same as functions, and have no obvious counterpart in Haskell.
  3. Inheritance (maybe)
  4. Template functions, template classes, etc.

Building Interfaces to C++

  • IO inside describes how to interface to a C++ library using the "export C" declaration (in C++) which makes it look like a C library. This seems to be the standard technique for bridging the gap between Haskell and C++.
  • CPlusPlus from Haskell describes "the hard way" of interfacing to C++, using the mangled C++ names directly without using "export C". It also suggests the possibility of a more automated approach using gcc-xml.
  • Hacanon automatically generates an FFI to C++ using Template Haskell, but its author has placed it "on hold" and sees some inherent flaws in using Template Haskell. (See David Himmelstrup, 2006, "About Lemmih", accessed 20 June 2009)
    • Hacanon-light is a reduced form of Hacanon, but with the same problems involving Template Haskell. (See ibid.)
    • ZeroTH (zeroth) fixes the problems of Hacanon and Hacanon-light. ZeroTH by itself only removes Template Haskell dependencies from Haskell programs; so, you could use either (Hacanon + ZeroTH) or (Hacanon-light + ZeroTH), but not ZeroTH by itself, to generate C++ bindings.
  • fficxx (“eff fix”; repository) is an automatic haskell Foreign Function Interface (FFI) generator to C++.
  • Hoppy generates bindings to C++ code from API descriptions written in Haskell, and supports exceptions, (limited) templates, callbacks, and garbage collection. Basic C++ standard library bindings are also included.
  • SWIG (Simplified Wrapper and Interface Generator) can be used to connect C and C++ with many languages, such as Python, Tcl, Java, several versions of Lisp, and OCAML), but alas, not Haskell. Or at least not directly. But with MissingPy, which provides access to the Python interpreter, it might be possible to do this indirectly: first, make the C++ library accessible to Python (already done, in many cases), then, let your Haskell program use the Python interpreter to make calls into the C++ library. Maybe this is also possible with some other scripting languages.