Open jonniediegelman opened 1 year ago
Ah, so the trouble there is that MallocArray's are expecting to be given a pointer to memory that has been manually allocated with malloc
. This could technically still work if for Array
s (or more generally DenseArray
s -- but not all AbstractArray
s) if you could guarantee that the memory backing the Array
would not be garbage collected by Julia in the meanwhile, and that you wouldn't ever attempt to free
the resulting MallocArray
.
If you can guarantee for your use case that Julia won't GC the underlying memory and wanted to implement a method like this, I'd accept a PR -- but it should probably convert to StaticTools.ArrayView
(which also just has fields of pointer, length, and size) rather than StaticTools.MallocArray
to ensure the resulting object can't be accidentally free
d (because that would be bad).
In the meanwhile, we do also have this method (which works on any AbstractArray and just copies the data to a new MallocArray):
julia> a = collect(1:5)
5-element Vector{Int64}:
1
2
3
4
5
julia> MallocArray(a)
5-element MallocVector{Int64}:
1
2
3
4
5
Okay, thanks! I didn't know about ArrayView
, it seems like that's what I actually want here.
Cool! PRs welcome if you want to change anything here!
I find
MallocArray
useful for working withccall
because it allows me to more easily pass in ref-wrapped structs that contain arrays. But it's a little clunky to manually have to convert from a plainArray
to aMallocArray
. Would there be anything wrong with having a default conversion like this?