Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig / C++ Interop

tuple.app

Post reply on HN
Print view View original

11–16 of 16 posts

Re: Zig / C++ Interop

#11

Post by swiftcoder »

kccqzy wrote: post #10
swiftcoder wrote: post #2

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

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

Re: Zig / C++ Interop

#13

Post by Jeaye »

pyrolistical wrote: post #9

It’s just both using c abi right?

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.

Re: Zig / C++ Interop

#15

Post by marler8997 »

Jeaye wrote: post #13
pyrolistical wrote: post #9

It’s just both using c abi right?

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 doabl…

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);

    // ...

}

Re: Zig / C++ Interop

#16

Post by pjmlp »

swiftcoder wrote: post #11
kccqzy wrote: post #10

Earlier quoted context omitted.

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

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

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