Mirror of forum.nim-lang.org

10916 :: Struggling to understand use of ptr object Types

• jhwbarlow (orginal) [2024-01-25T17:48:56+01:00] view original

  Hi All,

  New to Nim (background is Go, Python, Java/C#, very rusty C) and struggling to understand the use for ptr object types.

  The docs say

  As a syntactical extension, object types can be anonymous if declared in a type section via the ref object or ptr object notations

  This seems to work as I would expect using the constructor syntax for ref object types (the result is basically what you would consider a "normal" type in Java or a * type in Go, right?) - so I can mutate it in procs/methods without copying it.

  type Person = ref object
      name: string
  
  var person = Person(name: "James")
  echo person.name
  Run

  But I am struggling to construct a ref object object. I either cannot construct it with a compiler error, or I get a SIGSEGV on the create()d memory at runtime. I can construct and take a pointer to a "normal" object just fine. So what is the use case for ptr object. This doesn't seem to be discussed in the docs at all.

  type Cat = object
      name: string
  
  type DangerousCat = ptr object
      name: string
      enjoysMemoryLeaks: bool
  
  # All good, can make pointer to normal object type
  var cat = Cat.create()
  cat[] = Cat(name: "Top Cat")
  echo cat.name
  dealloc(cat)
  
  # Compile Error: object constructor needs an object type
  var dangerCat = DangerousCat.create()
  dangerCat[] = DangerousCat(name: "Garfield")
  echo dangerCat.name
  dealloc(dangerCat)
  
  # SIGSEGV: Illegal storage access
  var dangerCatSigSegV = DangerousCat.create()
  dangerCatSigSegV.name = "Garfield"
  echo dangerCatSigSegV.name
  dealloc(dangerCatSigSegV)
  Run

  PS. This is purely for curiousity, I know that the ptr stuff has very limited application in real life and I should be using ref for my objects (I guess like in Go, using *Struct instead of Struct 99% of the time unless it is a small struct staying locally in the current function...)

  Thanks!

---

• mratsim (orginal) [2024-01-25T18:06:20+01:00] view original

  A ptr object needs to be allocated first with alloc, alloc0 and then initialized, like in C. There is no convenience for constructor-like procs, it's an escape hatch for low-level programming and if you need that escape hatch it's likely that even if the stdlib tried to provide sugar for you, you will need to customize it or worse it might go in your way.

---

• Araq (orginal) [2024-01-25T18:12:41+01:00] view original

  Cat.create() creates a ptr Cat type, DangerousCat.create() creates a ptr DangerousCat type which is a pointer to a pointer so the assignment to dangerCatSigSegV.name can only fail.

---

• jhwbarlow (orginal) [2024-01-25T18:23:43+01:00] view original

  Wow quick replies, thanks :)

  Is create() not just a convenience wrapper around alloc()? It looks like it just takes sizeof(T) for you to avoid you doing that yourself and then casts it nicely for you?

  cast[ptr T](alloc0(sizeof(T) * size))
  Run

  I was on that train of thought myself when I noticed echo DangerousCat.sizeof is 8 bytes/64 bits so the size of a pointer and not the size of the "underlying" struct itself.

  Is there an easy way to get the sizeof the underlying type? Basically the same way you would do malloc() in C would be malloc(sizeof(DangerousCat)) and make DangerousCat not a ptr object... so I seem to have come full-circle on the "don't use ptr object" for type definitions argument!

---

• Araq (orginal) [2024-01-25T22:38:57+01:00] view original

  You are confused about absolutely nothing. create does exactly what you think it does, namely cast[ptr T](alloc0(sizeof(T) * size)) and it's just that you passed the wrong T. You can conclude from that that ptr object is to be avoided but in reality it's just that create is not very useful -- when you use ptr it's usually for C interop or custom allocation needs. In these cases the alloc0 (Nim's allocator) is rarely what you want.

---