What makes C++ FFI painful?
Lyle Kopnicky
lists at qseep.net
Thu Oct 31 18:15:51 UTC 2024
Not to mention name mangling, since method names do not export as simple C
function names. (Not unlike GHC’s Z-encoding.) I think the way that’s
usually dealt with is to have a C wrapper and declare it as extern “C”?
On Thu, Oct 31, 2024 at 11:25 AM Ben Gamari <ben at smart-cactus.org> wrote:
> Hécate via ghc-devs <ghc-devs at haskell.org> writes:
>
> > Hi devs,
> >
> > Pardon me for the naïve question. I know that C++ FFI is *hard* in
> > Haskell. From the perspective of an end-user I have heard that `text`'s
> > new UTF-8 validation caused problems when released, as it relied on C++
> > code, but I never had any problems with it personally. From the GHC
> > perspective, what makes C++ a difficult language to interface with?
> >
> There are a few reasons for this. First, there are considerations due to
> the language itself:
>
> * C++ has an object system which our binding generators do not
> currently make any attempt to capture. Consequently, developing
> bindings to C++ libraries written in an object-oriented style can
> require a fair amount of work.
>
> * the prevalence of C++'s template system means that one may need to
> generate one or more C++ snippets to instantiate an interface before
> one can even begin thinking about binding to the interface. This can
> be particularly tricky in libraries where you may want polymorphism
> in the Haskell binding to be reflected in the C++ instantiation.
>
> * Dealing with C++'s exception system requires great care when
> developing bindings.
>
> * The language itself is otherwise vast in scope, with numerous
> features that don't play well with others. Thankfully, usually C++
> library authors who intend for their work to be bound by others often
> restrict themselves to easily-bound features in their outward-facing
> interfaces.
>
> Perhaps more significantly, there are also a variety of practical
> considerations:
>
> * there are three implementations of the C++ standard library in common
> use today (libstdc++, libc++, MSVC). Determining which library should be
> used on a particular platform, and subsequently *how* to compile/link
> against it, is quite non-trivial (e.g. see #20010). The
> `system-cxx-std-lib` meta-package introduced in GHC 9.2 was aimed
> at improving this situation for Haskell packages by making GHC
> responsible for determining this configuration in such a way that
> users can easily depend upon.
>
> * even once you have compiled your program, linking against the C++
> standard library introduces a dynamic library dependency on most
> platforms. This is problematic as C++ standard library availability
> and installation path is not nearly as consistent as the C standard
> library. This is particularly problematic on Windows, where dynamic
> linking is already fraught and non-MSVC runtime dependencies are
> not widely available (e.g. [1])
>
> * Code generated by C++ compilers tends to use less-common relocation
> types, uncovering new and exciting ways for GHC's RTS linker to crash
> (e.g. see #21618)
>
> * To make matters worse, C++11 introduced an ABI breakage to optimise
> the representation of `std::string`. This was in the past a source of
> linking failures due to linking differently-compiled objects into the
> same library/executable. Thankfully most people have moved to the new
> ABI at this point so it's rare to see this manifest in the wild
> except when linking against ancient proprietary binaries.
>
> All-in-all, the difficulty is just death by a thousand cuts, often due
> to platform-dependent toolchain issues, many even entirely independent
> of Haskell.
>
> Does this help?
>
> - Ben
>
>
> [1] https://github.com/haskell/ghcup-hs/issues/745
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241031/86d33612/attachment.html>
More information about the ghc-devs
mailing list