Recent searches
Search options
Are there special considerations wrt FFI for languages like C#, Rust, Zig, Odin, Nim, Go for C functions that take array of pointers - is that substantially worse vs an array of values? (eg imagine a function that takes an arbitrary number of float arrays, vs a function that takes a single float array that has all streams combined and interleaved)
@zeux with regards to rust the only thing that occurs to me is having to handle lengths.
With a single array you can do `unsafe{ slice::from_raw_parts(ptr, len) }`. With an array of arrays you... have to work slightly harder if you're trying to avoid reallocating the outer array. I'd have to look at a concrete case but I think what I'd end up doing in many cases is `struct ArrayOfArrays { ptrs: &[*const f32], lens: &[usize] }` (or however the length data is passed to me from C) and then have `impl Index for ArrayOfArrays { fn index(&self, idx: usize) -> &[f32] { unsafe { slice::from_raw_parts(self.ptrs[idx], self.lens[idx]) } }`.
Realistically in most cases just re-allocating the outer array immediately at the FFI boundary is an option too (allowing for a `Vec<&[f32]>`)
@zeux In my experience that depends on the ownership semantics of the pointers.
If they are also allocated by the C side, and are not directly indirected by the calling side, then it doesn't matter.
If you want to avoid "unsafe" on the calling side (for those that have it,) and still dereference them, every individual pointer is a PITA.