Vraag & Antwoord
circular reference - kan iemand mij dit toelichten
Ik ben net begonnet met .NET en in het leerboek staat iets over circular references (in het kader van de garbage collector). Dit is het voorbeeld wat wordt gegeven:
public Widget ChildWidget;
public Widget Parent;
GrandParent = new Widget(); GrandParent.ChildWidget = new Widget();
Parent = GrandParent.ChildWidget;
Parent.ChildWidget = new Widget();
Child = Parent.ChildWidget;
Child.Parent = Parent;
GrandParent = null;
When the Grandparent variable is set to nothing, the Widget objects represented by
Parent and Child are left referring only to each other - a circular reference
Ik zie dat Parent en Child.Parent nu naar widgets verwijzen die niet meer bestaan maar ik snap het zinnetje "[i:1dbf7893bf]Parent and Child are left referring only to each other - a circular reference[/i:1dbf7893bf]" niet. Child verwijst toch naar een geldig widget object ? (nl. Parent.ChildWidget).
Als iemand dit voor mij zou kunnen toelichten, heel graag !
- hier staat echt alles over dit thema:
wij gaan het niet overtypen/copyen….
- [quote:05667c14ae="andre@home"]hier staat echt alles over dit thema:
wij gaan het niet overtypen/copyen….[/quote:05667c14ae]
de vraag is waarom in het genoemde voorbeeld sprake is van een circular reference want behalve dat er 2 pointers zijn die naar een niet meer bestaand object verwijzen zie ik geen circular reference..
maar laat maar… ik word zo moe van dit soort antwoorden.
Slotje graag !…
- iets…? Dit is in Python.
All Python objects have a reference count. When an object is initialized, its reference count is set to 1. When other objects want to hold a reference to it (that object is added to a list, say), its reference count must be increased. When that other object no longer needs a reference, the reference count is decremented. When an object's reference count reaches 0, it is destroyed. This is reference counting in a nutshell.
Whereas some languages, such as Java, use full-blown garbage collecting, reference counting is an attractive method because it is easy to implement and light on resources. Reference counting does have its downside, though. Neglecting to decrement an object's reference count will result in leaked memory. Also, it is possible to create circular references, which prevents the objects involved in the circle from ever being deallocated.
It's worth having a closer look at circular references, because if you're not aware of the issue, you'll likely get bitten. In the simplest case, a circular reference involves two objects A and B, where A holds a reference to B and B holds a reference to A. A typical example is a hierarchy of objects where each object has a parent and child. The parent points to its child, and the child points to its parent.
window = Window()
widget = Widget()
window.child = widget
widget.parent = window
This creates a circular reference between window and widget. Deleting either of these objects, or even when the scope is left, will not deallocate the memory used, and so the result is a memory leak. The documentation's advice on the issue is, "don't do it." In all fairness, this is pretty good advice. If you have a circular reference, it's possible your design is more complicated than it ought to be. Still, in some situations, circular assignments are warranted, and the only way to prevent leaked memory is to explicitly break the cycle yourself.
Then, when the scope is left, the memory will be deallocated properly. Python 2.0 will provide a garbage collector to handle this problem, but its performance is questionable, and it remains to be seen if this will be enabled by default once Python 2.0 is released.
When you're programming strictly with Python, you don't have to worry about the particulars of reference counting, except to avoid cyclical references. Programming with Python/C is a different story, however. If you forget to decrement an object's reference, memory will be leaked, destructors won't be called, and the result will be a broken mess. Or, decreasing an object's reference too many times is a sure way to make the Python interpreter crash and burn. To make matters worse, sometimes it's not entirely obvious when you're supposed to increase or decrease an object's reference. The good news is that this doesn't remain a mystery forever. It doesn't take long to learn the caveats and discover that things really do make sense in the end.
In Python, the references are owned, not the objects. When a new object is created, some other object (the creator) owns a reference to that object. It is also possible for a function to borrow a reference. Consider the case when an object is passed to some function that does some work on it, say sets an attribute or removes an element if it's a tuple, and then returns. This function needn't increment and then decrement the reference. It is said to borrow the reference. References may also be stolen. A function steals a reference when the calling function does not explicitly increase the reference for the function being called. Not many functions steal references, but you should know that some do.
The two macros used to increase and decrease references are Py_INCREF and Py_DECREF respectively. Py_INCREF increments an object's reference count by one, while Py_DECREF decrements it by one and calls the object's deallocator if it reaches 0. Now's a good time to put the reference counting issue on the backburner. We're going to revisit it from time to time as we take a closer look at the API. [/quote:8869667d09]
Beantwoord deze vraag
Dit is een gearchiveerde pagina. Antwoorden is niet meer mogelijk.