What makes C++ FFI painful?

[Lyle Kopnicky]

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>