Soren Roth
01/29/2025, 6:03 PMCValuesRef<*>
for the object. I've seen the guidance to use StableRef
to swim "kotlin to kotlin through c", but I am not invoking a callback, the c api is using the objective-c object itself.
cinterop binding: some_c_fun(objcObj: CValuesRef<*>?)
actual c function: some_c_func(void* objcObj)
what I am trying in kotlin: some_c_func(StableRef.create(myObjcObj).asCPointer())
passing in the CValuesRef cpointer is crashing in the c api which I think I understand, the c api would need to call or unwrap to the obj c object before using it. Is there any advice on how I can either construct the appropriate CValueRef or create some new c api that can bridge the divide?jw
01/29/2025, 6:33 PMmyObjcObj
today?jw
01/29/2025, 6:34 PMSoren Roth
01/29/2025, 6:34 PMjw
01/29/2025, 6:35 PMCStructVar
?Soren Roth
01/29/2025, 6:36 PMjw
01/29/2025, 6:37 PM.ptr
extension function on CPointed
which CStructVar
extends from.Soren Roth
01/29/2025, 6:37 PM@kotlinx.cinterop.ExternalObjCClass public interface MTLDeviceProtocol : platform.darwin.NSObjectProtocol
jw
01/29/2025, 6:40 PM.usePinned { }
, and then either .objcPtr
or addressOf(0)
. I've done a bit of objective-c interop, but I usually have to feel my way around as compared to raw C interop.Soren Roth
01/29/2025, 6:56 PMCValuesRef<*>
to the c api where it expects void*
parameter. I am guessing I can add some c api in the def file to expect a native pointer, then call my underlying function.jw
01/29/2025, 7:07 PMjw
01/29/2025, 7:07 PMjw
01/29/2025, 7:08 PMSoren Roth
01/30/2025, 12:16 AMdevice.objcPtr().usePinned { d ->
commandQueue.objcPtr().usePinned { q ->
metalView.objcPtr().usePinned { view ->
my_c_fun(
interpretCPointer<CPointed>(d.get()),
interpretCPointer<CPointed>(q.get()),
interpretCPointer<CPointed>(view.get())
)
}
}
}
not sure what will happen when the underlying things are referencedjw
01/30/2025, 12:18 AMSoren Roth
01/30/2025, 12:26 AMobjcPtr
on the Pinned<MTLDeviceProtocol>
was causing some unknown exception in calling a method on it on objc land. Reverting it back to calling objcPtr()
on the actual underlying NSObjects makes it work, which makes sense to me.