Re^3: XS Modules - why and when?

XS is always C, but can call into anything that exposes C-compatible functions in a shared library. So, C works, and C++ works as long as the author of the C++ module exposes plain-old-functions with C calling convention. There are other languages like Rust that can expose C functions from a compiled library even though the library was generated from Rust code. In fact, quite a lot of compiled languages can expose C library APIs just because C is sort of like a common meeting ground for interoperation and language designers want their modules to be widely usable. But XS can't just call into arbitrary other languages on their home turf.

Also I'd hesitate to call C# a compiled language. It's more like a bytecode interpreted language with optional just-in-time compilation. I don't think it can generate .so or .dll files with C calling convention. (but I'm too lazy to go find out)

Comment on Re^3: XS Modules - why and when?

Replies are listed 'Best First'.
Re^4: XS Modules - why and when? by GrandFather (Saint) on Dec 05, 2023 at 21:26 UTC
It is possible to wrap C# in C++, but it's something of a pain. Mind you, in my mind anything to do with C# is a pain so take from that what you want! Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond	[reply]
Re^4: XS Modules - why and when? by eyepopslikeamosquito (Archbishop) on Dec 05, 2023 at 22:54 UTC
> I'd hesitate to call C# a compiled language. It's more like a bytecode interpreted language with optional just-in-time compilation Agreed. And Just-in-time compilation and Adaptive optimization further muddy the performance waters. I'd call C# a statically-typed language, while Perl is dynamically-typed. Note BTW that (statically-typed) C/C++ can also do JIT/Adaptive optimization nowadays via LLVM and Clang. As discussed in more detail here, static typing usually results in compiled code that executes faster. 👁️🍾👍🦟	[reply]