Zig / C++ Interop
tuple.app
Zig / C++ Interop
1–10 of 16 posts
Re: Zig / C++ Interop
#2This has reawakened the nightmares about Objective-C++
Re: Zig / C++ Interop
#3This idea about communicating size/alignment is actually something we're doing on the port of RediSearch to Rust [0]. We have an "opaque sized type" which is declared on the Rust-side, and has its size & alignment communicated to the C-side via cbindgen. The C-side has no visibility into the fields, but it can still allocate it on the stack.
It's a bit ugly due to cbindgen not supporting const-generic expressions and macro-expansion being nightly-only. It seems like this will be a generally useful mechanism to be able to use values which are not traditionally FFI-safe across FFI boundaries.
[0]: https://github.com/RediSearch/RediSearch/blob/cfd364fa2a47eb...
Re: Zig / C++ Interop
#4> When you want to embed a type, you need its definition, but you don’t actually need the full definition. You just need the size/alignment.
Aren't there ABI cases where e.g.
struct foo { float X, Y; }
struct { char[8]; }
Re: Zig / C++ Interop
#5> When you want to embed a type, you need its definition, but you don’t actually need the full definition. You just need the size/alignment. Aren't there ABI cases where e.g. struct foo { float X, Y; } would be passed in e.g. fp registers whereas struct { char[8]; } would not?
Yes. For example consider this function to add two 2D points, which accepts and returns all variables entirely in xmm registers: https://gcc.godbolt.org/z/hPGKrh6W4 (surprisingly, gcc generates some fairly odd assembly code here)
Re: Zig / C++ Interop
#6> When you want to embed a type, you need its definition, but you don’t actually need the full definition. You just need the size/alignment. Aren't there ABI cases where e.g. struct foo { float X, Y; } would be passed in e.g. fp registers whereas struct { char[8]; } would not?
Yeah this is correct. You don't want to pass these values around "by value" but, you should be able to "embed them" and pass "pointers to them". It's a middle-ground between a completely opaque type which you would also pass around by address, but, with the added benefit that you allocate your own storage for it.
I sort of mentioned this in the blog but this is good clarification.
> if you want to pass a shared_ptr to Zig, you need to pass a pointer to the shared pointer
For lore, I believe this GitHub thread is where I first learned about the how types of the same size/alignment can still have different ABIs :) https://github.com/microsoft/win32metadata/issues/623#issuec...
Re: Zig / C++ Interop
#7> When you want to embed a type, you need its definition, but you don’t actually need the full definition. You just need the size/alignment. Aren't there ABI cases where e.g. struct foo { float X, Y; } would be passed in e.g. fp registers whereas struct { char[8]; } would not?
Yes. For example consider this function to add two 2D points, which accepts and returns all variables entirely in xmm registers: https://gcc.godbolt.org/z/hPGKrh6W4 (surprisingly, gcc generates some fairly odd assembly code here)
It's fixed if you pass -fno-trapping-math. There could be junk in the upper half of the registers that causes a floating-point exception.
Re: Zig / C++ Interop
#8Earlier quoted context omitted.
Yes. For example consider this function to add two 2D points, which accepts and returns all variables entirely in xmm registers: https://gcc.godbolt.org/z/hPGKrh6W4 (surprisingly, gcc generates some fairly odd assembly code here)
It's fixed if you pass -fno-trapping-math. There could be junk in the upper half of the registers that causes a floating-point exception.
Oh, that explains the seemingly useless movs. Thank you! I simply thought that it was a bug, since clang did not emit them.
Re: Zig / C++ Interop
#9It’s just both using c abi right?
Re: Zig / C++ Interop
#10This has reawakened the nightmares about Objective-C++
How so? Having written Objective-C and C++ separately but never written Objective-C++ before, I don't understand what's the hate it. Some of my favorite Mac apps from a decade ago were written in Objective-C++. I think Chrome still has some parts in Objective-C++.