Mirror of forum.nim-lang.org

10490 :: How to define a =copy hook for a distinct cstring type?

• Isofruit (orginal) [2023-09-17T20:40:38+02:00] view original

  For interacting with the GTK library I call some functions that hand me a c-string (char*) that my code owns going forward. I want to have those strings in a custom distinct cstring type and define a =copy hook for those strings for use with nim's ARC/ORC system.

  My minimal example looks likes this:

  
  type OwnedGtkString* = distinct cstring
  
  proc `=copy`*(dest: var OwnedGtkString, source: OwnedGtkString) =
    let areSameObject = pointer(source) == pointer(dest)
    if areSameObject:
      return
    
    `=destroy`(dest)
    wasMoved(dest)
    
    dest = source
  
  let x: OwnedGtkString = "lala".OwnedGtkString
  let y = x
  echo x.pointer.repr
  echo y.pointer.repr
  Run

  Naturally this is naive implementation. This doesn't work because dest = source triggers the =copy hook again, making the entire thing recursive.

  Now what else am I supposed to use here? copyMem would be an option if I could know how long the string is. Given that =copy is supposed to work for a whole breadth of different cstrings that seems non-feasible.

  I also can't do simply assignments like this as that triggers the copy proc again.

  So how is it supposed to be possible to define a copy-hook for a distinct cstring type?

---

• elcritch (orginal) [2023-09-17T21:04:08+02:00] view original

  You might try a type conversion, like cstring(dest) = cstring(source), or even a cast.

---

• sky_khan (orginal) [2023-09-17T21:06:53+02:00] view original

  If Nim side owns the string why dont you just convert it to Nim string in the first place ? Otherwise you have to scan all cstring to query it's size every time but getting cstring pointer out of Nim string is effortless.

---

• Isofruit (orginal) [2023-09-17T21:07:14+02:00] view original

  That actually already did it!

  Question though: That'll enable a pointer-copy, is there a way to copy c-strings that you don't know the size of?

---

• Isofruit (orginal) [2023-09-17T21:39:23+02:00] view original

  Because in the end that memory also needs to be freed via g_free, does it not? That I can only do by defining a custom destructor on it that calls g_free to deallocate. And to be sure that nowhere accidentally somebody copies the pointer and then the destructors causes a double-free, I also define a custom =copy hook.

---

• Araq (orginal) [2023-09-17T22:06:57+02:00] view original

  That'll enable a pointer-copy, is there a way to copy c-strings that you don't know the size of?

  Well you can count the size via strlen.

---

• sky_khan (orginal) [2023-09-17T22:25:20+02:00] view original

  Sure. Still, how will your users will use cstring ? Nim standard lib, strutils, strformat.. expects Nim string. If you keep it as cstring in a Nim object, it will have to be converted to Nim string on-the-fly on every call site every time it's used. I'm just saying maybe you should consider to copy it to Nim string to store it in Nim side and call g_free on the original.

---

• Isofruit (orginal) [2023-09-17T22:27:04+02:00] view original

  Is strlen the proc c_strlen in std/segfaults? If so, how do you use it?

  I tried this

  import std/segfaults
  let a: cstring = "lalala"
  echo a.c_strlen()
  Run

  as well as just

  let a: cstring = "lalala"
  echo a.strlen
  Run

  In case it's a proc somewhere in std/systems that I just fail to find. Neither can compile because they can't find strlen or c_strlen.

---

• icedquinn (orginal) [2023-09-17T23:05:00+02:00] view original

  If Nim side owns the string why dont you just convert it to Nim string in the first place ? Otherwise you have to scan all cstring to query it's size every time but getting cstring pointer out of Nim string is effortless.

  Do Nim strings hold the null terminator at the end like Delphi's bodged strings did? If so, might not be a bad idea unless its a section of code where that is going to invite a lot of undesired copying.

---

• icedquinn (orginal) [2023-09-17T23:12:10+02:00] view original

  Is strlen the proc c_strlen in std/segfaults? If so, how do you use it?

  I believe it's just .len overloaded for an object of type cstring.

  Distinct types pretend to be a completely new type--you have to take extra steps to allow those old behaviors back in to the new type. You can also typecast back to the backing type for free (ex cast[cstring](protected).len.) Such is also one way to get around your copy constructors. You would need to typecast to the backing type--which does not have these copy triggers--and then back to the protected type to return it.

  I've tried abusing =copy and such for pointer trickery in the past (in my postbox repo <https://git.sr.ht/~icedquinn/icedpostbox>) and it was kind of a pain. I don't think I would do so again without a real need (like profiling showing you are copying strings back and forth too much, or if you absolutely need a parallel reference tracer for keeping game textures loaded or such.)

---

• sky_khan (orginal) [2023-09-17T23:32:51+02:00] view original

  AFAIK, yes it does. Nim's strings basically same as Pascal/Delphi strings. It keeps size of it in a hidden field and they're null terminated.

---