[Info-vax] Viable versus ideal programming languages
Dan Cross
cross at spitfire.i.gajendra.net
Wed Mar 23 15:38:25 EDT 2022
In article <t1fpab$v69$1 at dont-email.me>,
Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2022-03-22, Dan Cross <cross at spitfire.i.gajendra.net> wrote:
>> In article <t1d53c$ges$1 at dont-email.me>,
>> Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>>
>>>BTW #2, you can only easily call C++ code from a non-C++ program by
>>>providing a C interface in the C++ library so you are back to using
>>>C as an interface language even with C++...
>>
>> That's not precisely true; you're using an ABI that the C
>> compiler targets, but that's qualitatively different than using
>> the C language. For example, in Rust, I can define structures
>> that use the layout of the system's native ABI, or functions
>> that use the ABI's calling convention, etc. In my work, that
>> usually implies calling between Rust and primitives written in
>> assembly, but not C. In some sense, the connection with C is
>> incidental, though admittedly many such ABIs were designed as a
>> target for C primarily.
>>
>
>Does Rust have a C++ type name mangling problem when trying to call
>a Rust library function from C ?
No. You can export unmangled names trivially.
>It seems that everyone falls back to C interface mode when trying
>to export functions for use by another language. A quick look around
>seems to show that Rust does the same.
I suppose that if one's definition of a well-defined ABI is what
you are calling a "C interface mode" that's true, but most ABIs
are language-independent.
>It would be nice to have a richer interface standard that handles calling
>between both OO and procedural languages natively but we are back once
>again to C being viable if not ideal.
It's curious to me how VMS had this from very early on (e.g.,
https://vmssoftware.com/docs/VSI_CALLING_STD.pdf) and it was
rightfully lauded as a boon for cross-language interoperability,
but when people point to ABIs on other systems it's assumed to
be a C thing.
>(And before anyone mentions the VMS common language environment, it
>doesn't have support for OO languages.)
Perhaps you mean that it doesn't have baked-in support for
method dispatch via vtables and the like. But then, the System
V ABI for modern architectures does (or rather, it defers to the
Itanium ABI). Indeed, the latest VSI caling standard document
refers to the SysV C++ ABI, which refers to the Itanium ABI,
which specifies object layout and method invocation in detail:
https://itanium-cxx-abi.github.io/cxx-abi/abi.html
So in some sense, a lot of things _are_ specified, by the VMS
standard, at least for one "OO" language.
- Dan C.
More information about the Info-vax
mailing list