Mirror of forum.nim-lang.org

11294 :: List of GC'ed types

• sls1005 (orginal) [2024-03-25T14:01:04+01:00] view original

  I've just compiled a list of GC'ed or pointer-like types, because they're too easy to forget.

  Type	Also known as	GC'ed	Can be nil	Can form cycle
  seq	Sequences	True	False (previously true)	(normally) False
  string	Strings	True	False (previously true)	False
  cstring	Compatible strings	False	True	False
  ref	(Traced) references	True	True	True
  ptr	Pointers	False	True	True
  proc {.closure.}	Closures	True	True	True
  (proc) and not (proc {.closure.})	Non-closure procedural types	False	True	False

  By simplifing the above, we get:

  \\	Can be nil	Can not be nil
  GC'ed	ref, closures	string, seq
  Not GC'ed	ptr, cstring, non-closure procedural types	Most of the other types

---

• scippie (orginal) [2024-03-25T14:16:48+01:00] view original

  I'm still learning Nim, so maybe I am not seeing enough details, but I find this table to be logical. I do have a very strong C/C++/ASM/... background, and have long ago written my own Turbo Pascal compiler so maybe that's why I see it that way.

  Things like a seq and string are objects that are 'constructed' and 'destructed', so they clean up after themselves when they leave scope.

  Pointers are pointing at other things that should clean up themselves, so it's logical that they don't clean up.

  I don't know about closures, I believe they will become (like all procs, on any scope) static code on a lower level and then they are never cleaned up nor should they be. They are not like closures in scripted languages where GCing them is necessary and expected.

---

• arnetheduck (orginal) [2024-03-25T14:26:30+01:00] view original

  Nice! This would be an excellent addition to typetraits (isGcType or something) where it would work recursively for objects and tuples - I've often wanted such a utility to avoid passing GC:d stuff across thread boundaries etc.

---

• 4n0n4me (orginal) [2024-03-25T14:37:12+01:00] view original

  I am not familiar with these things, but I think when you pass a closure to a function as a callback, you pass the "environment" together with the function pointer which points to some code in code segment. I guess that's why closures are GC'ed.

---

• scippie (orginal) [2024-03-25T15:49:55+01:00] view original

  Either that, or the environment is passed as extra parameters, in which case no clean up should be necessary, but you're right, it will probably be something like that and we should not worry about it.

---

• sls1005 (orginal) [2024-03-26T09:59:05+01:00] view original

  I don't know if it is necessary to be implemented like that, but closure is listed in the manual as one of the four types that contain GC'ed memory.

---

• PMunch (orginal) [2024-04-02T14:35:50+02:00] view original

  This should be put into the manual somewhere!

  As for the closure thing they get turned into a pointer to a normal procedure and a pointer to an environment. This environment contains all the state captured by the closure. When the closure is called it's actually a static procedure which is called, but it is given the environment pointer to work as a closure. Because of this environment they are GC'ed as the environment must be freed at some point.

---