Mirror of forum.nim-lang.org

2943 :: pointer to array?

• jxy (orginal) [2017-05-05T21:35:56+02:00] view original

  Hi, I'm trying to interface some C library where the library function accepts a function pointer for callbacks.

  proc libfun(fun:proc(x:pointer; n:ptr cint)) {.importc:"libfun", header:"mylib.h".}
  Run

  I'm trying to write this fun proc in Nim, and pass it to libfun. How do I treat this x:pointer as an array? I want to do simple things as *(x+int_number) in C. I'm currently doing cast[ref array[0..0,float]](x), and removing bounds checking. But is there a better way to do this in Nim?

---

• mashingan (orginal) [2017-05-06T00:18:15+02:00] view original

  maybe this should help?

  https://forum.nim-lang.org/t/1188#7366

---

• jxy (orginal) [2017-05-10T16:56:22+02:00] view original

  I'm using

  template asarray*[T](p:pointer):auto =
    type A{.unchecked.} = array[0..0,T]
    cast[ptr A](p)
  Run

  for now.

  Is there a difference between cast[ptr A](p) and cast[ref A](p) here?

---

• Krux02 (orginal) [2017-05-10T18:29:17+02:00] view original

  @jxy yes there is a difference betwen ref A and ptr A. When the ref is implemented as an std::shared_ptr (I think Araq mentioned an option once to do that), then ref A takes over the ownership and as soon as the reference is deleted, also the memory will be deleted. You don't want that, therefore don't use a ref.

---

• mashingan (orginal) [2017-05-11T00:51:28+02:00] view original

  .... an std::shared_ptr ... then ref A takes over the ownership

  Is it the same when the backend is C?

  Have compiler already warned if there's untracked reference cast to tracked reference?

---

• Krux02 (orginal) [2017-05-11T02:12:02+02:00] view original

  Honestly I don't know. I try to avoid ref as much as I try to avoid std::shared_ptr in C++ because for me they are semantically the same. But I know that the programming language Go does not have distinct types for ref and ptr. In that language a pointer simply keeps a block of memory during garbage collection alive, when the Go runtime knows about that pointer, and the pointer points to the garbage collected region of memory. A pointer to memory outside of the GC heap simply doesn't affect the garbage collector. Could be that Nim behaves similarly.

---