The purpose of weak references - Part I
The terminology "weak and strong references" is commonly used in the context of automatic reference counting. In the context of manual memory management, we talk about ownership, and owning and non-owning references.
While the terminology is different, those two different kinds of references represent the same concept, regardless of the underlying memory management model. Strong references are the equivalent of owning references, and weak references are the equivalent of non-owning references.
Understanding those relations can help us understand the purpose of weak references in automatic reference counting, and instead of thinking about them merely in the context of breaking reference cycles, we should think about them as non-owning references—in other words, additional references to an object instance that don't participate in its memory management, and could be invalidated after the object is released through other code and owning references.
Because non-owning (weak) references can become invalid, they are inherently dangerous to use. If you access such a reference after the object is released, you will be accessing invalid data and crash the application.
If they are dangerous, then why we are using them at all? What is their purpose? It would be much better if we could avoid writing such hazardous code.
Just like any other tool in the toolbox, non-owning or weak references can be
dangerous if misused or not used properly. Just like a
nil value can be
dangerous, they can be dangerous, too. But just like it is impossible to write
a non-trivial application that never uses
nil as a valid reference value, it is
similarly impossible to write such an application without using non-owning or weak
Yes, we should always avoid writing more dangerous code than is necessary, but we should also use it when it fits the purpose. Avoiding more dangerous code at all costs, can lead to unnecessary complex or convoluted code that is often slower than more simpler, yet seemingly more dangerous code. If the code is clean, simple, easy to follow and understand, then it will actually be safer than the more complicated code that avoids dangerous code for no good reason.
Manual memory management
Under manual memory management, the developer has the responsibility of manually releasing all constructed object instances, or delegating that process to another entity (commonly another object instance).
To do that, we need to keep a reference to the constructed object instance. The reference to the object instance that we use to free the object is called the owning reference. Any other reference we might have to that object will be a non-owning reference, and non-owning references must not be used to free the object.
In some scenarios, we can have more that one owning reference to a single object instance, but in such cases, we also need some mechanism that will notify us when one of those references is used to free the object, to avoid releasing the object multiple times.
We can also transfer ownership from the original reference to some other entity that will be responsible for releasing the object from that point on. In such cases, the original reference will no longer be the owning reference after the ownership transfer is complete.
The following examples show the basic principles of owning and non-owning references and ownership transfer.
procedure Foo; var Obj: TObject; // owning reference begin Obj := TObject.Create; try ... finally Obj.Free; end; end;
Owning and non-owning references:
procedure Foo; var Obj: TObject; // owning reference ObjRef: TObject; // non-owning reference, must not be used to free object begin Obj := TObject.Create; try ObjRef := Obj; ... finally Obj.Free; end; end;
procedure Foo(List: TObjectList); var Obj: TObject; // temporary owning reference begin Obj := TObject.Create; try List.Add(Obj); // ownership is transferred to List except Obj.Free; // in case of exception, ownership transfer is not completed raise; // and we need to release the object in that case end; end;
As previously mentioned, manual memory management requires having only one
owning reference, unless there is an additional mechanism involved in preventing
a double free under particular circumstances.
TComponent and its descendants
have such a mechanism built in.
One common coding pattern is the following:
procedure TMainForm.OnButtonClick(Sender: TObject); var Frm: TMyForm; begin Frm := TMyForm.Create(Application); try ... finally // even if we don't call Free here, the constructed form will still eventually // be released through its owner - the Application object instance Frm.Free; end; end;
In that example, a
TMyForm instance is constructed with an owner—the application
Application takes ownership of the constructed object, and it will
automatically release all owned object instances during its destruction process.
This is how all
TComponent-based classes behave. If they are constructed with
an owner, that owner component will be responsible for releasing them. If they own
other components, those will be released when that particular object instance is
But the above example releases the
TMyForm instance through its non-owning
Frm. Generally, such code would result in a double free and crash,
but in the case of
TComponent descendants, that does not happen because each
component with an owner will also remove itself from the owner's component list
during its destruction process, preventing a double free.
In this case, we basically have two owning references to an object instance, but its destruction process is coordinated through an inner class mechanism that allows such shared ownership.
However, that works only if one of the owning references is stored in another component's list of children. If we have two plain references to a component, there is no connection between the two to prevent a double free:
procedure TMainForm.OnButtonClick(Sender: TObject); var Frm1, Frm2: TMyForm; begin Frm1 := TMyForm.Create(Application); try Frm2 := Frm1; ... finally Frm1.Free; Frm2.Free; // this will cause a double free end; end;
The above example is a bit contrived, but by taking multiple references to object instances in more complicated code, we can easily cause a double free, or another common problem—dangling references.
In the above examples, we have seen what a non-owning reference technically looks like, by taking an additional reference to some object instance, but we have not seen a real-life example where doing so actually makes sense and it is not merely bad code.
One common pattern is having a parent-child relationship between object instances:
type TParent = class; TChild = class protected Parent: TParent; // non-owning reference public constructor Create(AParent: TParent); destructor Destroy; override; end; TParent = class public Child: TChild; // owning reference constructor Create; destructor Destroy; override; end; constructor TChild.Create(AParent: TParent); begin Parent := AParent; end; destructor TChild.Destroy; begin inherited; end; constructor TParent.Create; begin Child := TChild.Create(Self); end; destructor TParent.Destroy; begin Child.Free; inherited; end;
The parent owns child object instance, but child does not own its parent, even though it stores the reference to the parent. In such a parent-child relationship, we don't need to worry about dangling references, because the parent reference will never became a dangling pointer, as the parent always lives longer than its child object.
This code does not support changing the parent of a child instance, but this is also
possible, it just needs a bit more housekeeping code. We would need to
child reference from its parent to prevent a double free if we decide to break
For simplicity, in the above example, the parent has only a single child, and they belong to different classes. More often, the parent and child class are the same, and the parent will have the ability to hold two or more children instances. This pattern is the basis of various tree-like structures.
If you take a look at the
TComponent code, you will find that pattern there—each
component will have an owner (which can also be
nil, in which case the component
is the root component, and needs to be manually managed), and it can hold multiple
child components. A component that does not have any children is a leaf node.
You can argue that having a reference to a parent (owner) is not strictly necessary, as you can always find a particular child by traversing the structure through the root reference. However, such an approach is not always viable, as it can be too costly performance-wise, and sometimes hard to implement algorithmically if you don't have direct access to the root instance in the code scope where you are handling a tree node.
And if you store the root reference in each child, they you still have the same problem with holding a non-owning or weak reference, and you have just made the process of accessing the immediate parent more convoluted.
Another form of non-owning references is when you have two independent object instances that have some functional dependence outside an ownership relation.
An example of such non-owning relationship can be having an edit control which has an associated popup menu. The edit control will hold a non-owning reference to a menu, allowing invoking a menu when user right-clicks on the edit.
Now, the edit could be an owner of the menu instance, and we could avoid having a non-owning reference to a menu, but such a framework design would not be very efficient.
What if you have multiple edit controls that could share the same popup menu?
If an edit control takes a non-owning reference to a menu, then you can easily share that popup menu across different controls. On the other hand, if the edit is an owner of the popup menu, then for each edit you would need to construct a separate menu instance. Not very efficient, is it?
The problem with this kind of non-owning references where each object is independent
from the other, is that if we decide to free the popup menu for some reason, we
need to be able to notify the interested edit or other controls that the menu is no
longer available. In such a scenario, the control will just set the menu reference to
nil, and that will be an indicator that there is no popup menu functionality
associated with the control.
TComponent solves this problem by implementing a notification mechanism. When
you associate a menu with an edit control, the menu reference will be stored in the edit, but
the edit will also be added to the menu component's notification list. That way, the menu
can notify all registered components during its destruction process. However,
now you have a situation where menu holds a reference to the edit control, too. To
prevent accessing a dangling pointer, the edit needs to add the menu to its component
notification list. If the edit gets released before the menu, the menu will be able
to remove the edit reference from the notification list, and avoid problems with
accessing a destroyed instance.
If you use
TComponent descendants, you can use its notification system to
solve issues with dangling pointers when you need to create an association between
two components. If you need to store non-owning references between object
instances that don't belong to the
TComponent class hierarchy, you would need to
implement some similar mechanism to avoid a dangling pointer problem.
Under manual memory management, every reference to an object is the same, as there are no additional designators that will tell us whether a reference is an owning or non-owning one, and how we should deal with it. We can only determine that by inspecting the code logic. If the code logic is flawed, we will have issues with managing memory.
Because we don't need to explicitly mark object references as owning (strong) or non-owning (weak), it may seem like we don't need to think about their categorization under manual memory management, but in reality while we are writing or reading code, we can always tell which reference is strong and which ones are weak. If we cannot tell that, then we have a serious problem with that particular code.
Additionally, if we take a non-owning reference to a object, where that reference
can turn into a dangling pointer, we need to use some mechanism to avoid creating
dangling pointers. In other words, we need to be able to
nil such a reference
when the object is no longer valid, and that
nil value will be an indicator that
the particular functionality is not available.