What makes C++ FFI painful?

[Hécate]

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 <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
>
-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW:https://glitchbra.in
RUN: BSD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241101/628d69b6/attachment.html>