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 <b...@smart-cactus.org> wrote:
Hécate via ghc-devs <ghc-devs@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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
--
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW:https://glitchbra.in
RUN: BSD
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
