Re: What makes C++ FFI painful?

1 Nov 2024


      Thank you both. From what I understand, some it appears to be linked to 
the fact that C as the lowest common denominator, forces a conscious 
effort on the part of other languages to provide this "simplified" 
interface to their binary artifacts. Maybe crabi¹ will help in the future.
I knew this was a challenge but I understand better now. :)

Cheers,
Hécate

¹ "Interoperability between high-level programming languages that have 
safe data types", 
https://github.com/joshtriplett/rfcs/blob/crabi-v1/text/3470-crabi-v1.md

Le 31/10/2024 à 19:15, Lyle Kopnicky a écrit :
...
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  wrote:
Hécate via ghc-devs  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@haskell.org
    http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW:https://glitchbra.in
RUN: BSD