You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rather than declaring arguments (and struct fields) as Vector{IntPoint}, it would be more generic to allow AbstractVector{IntPoint}. This can still be passed to C libraries as long as it supports a pointer conversion, and you could check that the stride(array,1) == 1 so that it is contiguous — these will throw a MethodError for array types that don't support these operations.
(It also might be convenient to use const IntPoint = SVector{2,Int64}.)
I agree that passing vectors instead of structures is much better (I wrote some wrappers in my own code), since vectors natively support linear algebra for example.
However for point types there are two and a half possibilities that come to mind that would be even better than using a SVector{2,Int64}:
even more Julian: use an abstract type (StaticArray{Tuple{2}} comes to mind — this would allow both SVector and labelled vectors).
also, the coordinate type should also be left open (I use some fixed-point real numbers), as long as it is 64 bits long. This can even be enforced on the Julia side using type traits (dispatching via Val(sizeof(T))).
Rather than declaring arguments (and
struct
fields) asVector{IntPoint}
, it would be more generic to allowAbstractVector{IntPoint}
. This can still be passed to C libraries as long as it supports apointer
conversion, and you could check that thestride(array,1) == 1
so that it is contiguous — these will throw aMethodError
for array types that don't support these operations.(It also might be convenient to use
const IntPoint = SVector{2,Int64}
.)See also this discourse discussion
The text was updated successfully, but these errors were encountered: