GC Hell

BlitzMax Forums/BlitzMax Programming/GC Hell

The forum is locked. These are the original blitzbasic.com forums, kept so they can still be read. No new topics, replies or edits can be made here. To join in, head over to the Blitz3D+ forums.

@FlameDuck:
Good and clear design certainly help, sure.
On the other hand I really can't understand how people can seriously think that having cyclic references is a bad design per se. I've been hearing that here and there, and to me that's just pure nonsense.
And from the moment you have cyclic references AND a garbage collector that cannot handle them gracefully, you have to be very carefull *at the global level*. That is, ensuring there is no memory leak requires knowledge about the whole application.
With a full GC that's not true anymore. If an object is not collected, then it is still reachable. If it is not, it will be collected eventually. And that's it. No need to know the whole graph of references, which makes quite a difference.

So there is a real concern about memory leaks handling in BlitzMax. That's life and we just have to live with that, but saying otherwise won't help anyone.

Being pedantic won't help either.

@Leadwerks : There was a thread on the subject recently. You can get the reference count of an object by getting an integer pointer p (not reference) to your object, and use it to address p[-1] (or maybe [-2] etc, just test it). That's a hack but could certainly help you in your debugging. But to be of any use you'd need to be sure at any time which objects are *supposed* to be freed (but are not).