>I wish that when GC encountered a cycle it would just tell the programmer that they now have a leak, maybe even suggest where it could be fixed with one of those neat little IDE quick fixes, and continue chugging along.
Are you saying that cyclic data structures are always a bad idea? So no one should ever make a doubly-linked list?
Or, to take a case from a game I'm working on: I'm writing a set of GUI controls for the game's UI. There will almost always be at least a few controls on screen, so I have a WindowManager object that lives for the entire duration of the application and does, among other things, tasks like telling all of the controls to draw themselves, determining which control has focus, etc. The controls all have a reference to the WindowManager object (or whatever their direct parent is, once I start supporting more complex controls) so they can implement methods like onClick() { parent->removeGroupOfControls(); }
Even though the WindowManager is persistent, the individual controls come and go quite often. So if I was using a GC (I happen to be doing this in C++) that simply threw up its hands whenever it encountered a cycle, none of the controls would ever get garbage collected, leading to a huge memory leak over time.
Is this a case where you think cycles are appropriate? Or is there a better way to refactor this so it doesn't use cycles? (If someone has ideas for a better design, I would absolutely love to know.)
Are you saying that cyclic data structures are always a bad idea? So no one should ever make a doubly-linked list?
Or, to take a case from a game I'm working on: I'm writing a set of GUI controls for the game's UI. There will almost always be at least a few controls on screen, so I have a WindowManager object that lives for the entire duration of the application and does, among other things, tasks like telling all of the controls to draw themselves, determining which control has focus, etc. The controls all have a reference to the WindowManager object (or whatever their direct parent is, once I start supporting more complex controls) so they can implement methods like onClick() { parent->removeGroupOfControls(); }
Even though the WindowManager is persistent, the individual controls come and go quite often. So if I was using a GC (I happen to be doing this in C++) that simply threw up its hands whenever it encountered a cycle, none of the controls would ever get garbage collected, leading to a huge memory leak over time.
Is this a case where you think cycles are appropriate? Or is there a better way to refactor this so it doesn't use cycles? (If someone has ideas for a better design, I would absolutely love to know.)