I thought about introducing unsafeAddr for this purpose but since 'addr' is already unsafe, that's a weird name for it. maybe ffiAddr?
If you want to introduce xlen and xadd (not sure if I like the idea), xaddr might work.
I really can't understand why this is necessary. Just use var. If you want to document that the variable will not be modified, then add a comment.
That's needed to wrap C functions into a nice Nim-ish interface, and still do it without any performance loss.
I really can't understand why this is necessary. Just use var. If you want to document that the variable will not be modified, then add a comment.
But if the C function doesn't actually modify it, then it really isn't a var. The main problem is it causes a chain reaction all the way up with every proc needing to have var, and it is never modified.
Someone showed a thing where you can unsafe cast to a var as a workaround.
Another topic that seems related to this one
And considering this new topic, maybe there's no reason to use addr on let expressions after all. Maybe we just need some function argument type annotation that takes a pointer and this pointer doesn't get written to and does not escape the called function? So when we use this function it will accept both vars and lets? Just a random thought:
proc myCFunc(testPtr: const noescape ptr Int) {.importc.}
var i = 5
let j = 5
# All ok
myCFunc(5)
myCFunc(i)
myCFunc(j)
I'd love the first approach too.
I do need this functionality (taking the address of a let object) but as a workaround I will do like the following code for now.
let a = ... (1)
# let p = addr(a) isn't allowed
var b = ... (2)
let p = addr(b)
This works but I wonder how huge the copying overhead at (2) especially if sizeof(typeof(a)) is huge. Does compiler remove this verbose assignment at optimization?
I am now implementing msgpack binding and facing this problem for example when I build a msgpack buffer from a immutable message.