Zig / C++ Interop

Postedabout 2 months agoActiveabout 2 months ago

simonklee

110 points

15 comments

tuple.appTechstory

calmmixed

Debate

40/100

C++ZigInteropAbiSystems Programming

Key topics

C++

Zig

Interop

Abi

Systems Programming

The article discusses achieving interoperability between Zig and C++ by leveraging the C ABI, sparking a discussion on the complexities and challenges of interop, including size/alignment communication and ABI nuances.

Snapshot generated from the HN discussion

Discussion Activity

Light discussion

First comment

Peak period

3-6h

Avg / period

Comment distribution15 data points

Loading chart...

Based on 15 loaded comments

Key moments

01Story posted
Nov 11, 2025 at 3:09 AM EST
about 2 months ago
Step 01
02First comment
Nov 11, 2025 at 8:01 AM EST
5h after posting
Step 02
03Peak activity
4 comments in 3-6h
Hottest window of the conversation
Step 03
04Latest activity
Nov 12, 2025 at 4:53 PM EST
about 2 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (15 comments)

Showing 15 comments

swiftcoder

about 2 months ago

2 replies

This has reawakened the nightmares about Objective-C++

kccqzy

about 2 months ago

1 reply

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++.

swiftcoder

about 2 months ago

1 reply

I don't think anyone who could help it wrote software in Objective-C++ directly.

It was an unholy welding of the two languages that mostly let Objective-C apps adopt some libraries from the broader C++ ecosystem. Plus the occasional cross-platform C++ codebase used it as a thin shim to provide a Cocoa-based UI...

pjmlp

about 2 months ago

It is still around, even if documentation is only on archives.

nly

about 2 months ago

Objective C++ was great.

Rename a file to .mm and start using Objective C APIs. Very good interop

jcelerier

about 2 months ago

2 replies

> 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?

threeducks

about 2 months ago

1 reply

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)

anematode

about 2 months ago

1 reply

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.

threeducks

about 2 months ago

Oh, that explains the seemingly useless movs. Thank you! I simply thought that it was a bug, since clang did not emit them.

marler8997

about 2 months ago

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...

pyrolistical

about 2 months ago

2 replies

It’s just both using c abi right?

Jeaye

about 2 months ago

1 reply

Yeah, this isn't quite C++ interop on its own. It's C++ interop via C, which is an incredibly pertinent qualifier. Since we go through C, opaque pointers are needed for everything, we can't stack allocate C++ values, we need to write extern C wrappers for everything we want to do (like calling member fns), and we don't get any compile-time type/safety checking, due to the opaque pointers.

Direct C++ interop is doable, by embedding Clang into Zig and using its AST, but this is significantly more work and it needs to be done in the Zig compiler. As a Zig user, going through C is about as good as you can do, probably.

marler8997

about 2 months ago

It's a bit more than your typical "interop via C". With a "sized opaque" type you actually can stack allocate C++ values in Zig (and vice versa stack allocate Zig values in C++), i.e.

fn stackExample() void {

    var some_cpp_type: c.SomeCppType = undefined;
    c.some_cpp_type_ctor(&some_cpp_type);
    defer c.some_cpp_type_dtor(&some_cpp_type);

    // ...

}

swiftcoder

about 2 months ago

Seems like it. And the sizes are all hard-coded, which means you are probably wedded very tightly to a particular C++ compiler.

enricozb

about 2 months ago

This 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...

View full discussion on Hacker News

ID: 45885135Type: storyLast synced: 11/20/2025, 7:45:36 PM

Want the full context?

Jump to the original sources

Read the primary article or dive into the live Hacker News thread when you're ready.

Open link View on HN