template<typename RCImpl>
struct openvpn::RCWeak< RCImpl >::Controller
Controller structure for our ptr/weakptr implementation.
- Template Parameters
-
RCImpl | The ref count implementation |
For weak-referenceable objects, we must detach the refcount from the object and place it in Controller.
This struct implements 3 essential elements:
- A pointer to the parent (RCWeak enabled) object.
- A ref count on Controller via RC<RCImpl> inheritance.
- A ref count inside Controller via the RCImpl member 'rc'.
They are used as follows.
Controller::rc is the ref count of the object, and the inherited RCImpl is the ref count of the Controller itself. The 'parent' pointer is used to form a Strong (owning) pointer on demand if the Controller::rc refcount is greater than zero, or if not a nullptr Strong is returned.
An RCPtr<> will call intrusive_ptr_add_ref and intrusive_ptr_release helpers which will increment and decrement refcount_, which for RCWeak is an instance of RCWeak<>::ControllerRef. This ControllerRef instance will delegate those operations to the 'controller' member, which is an RCWeak<>::Controller referenced via an RCPtr<> instance inside ControllerRef. This is where the composed 'rc' refcount is modified.
The inherited RCImpl is controlled by the 'Controller::Ptr controller' member in ControllerRef via the member refcount_ and by the RCWeakPtr reaching in and manipulating it. Thus the object itself has 1 refcount on the controller and each weak ptr also holds a refcount on the controller.
When the last RCPtr on the object goes out of scope and decrements Controller::rc to zero, the object will be destroyed. If the only refcount on the controller is the ControllerRef, then the Controller instance will also be destroyed at this time. Otherwise the weak pointers to the controller will control that object's lifespan, but no further Strong pointers to the (now nonexistant) object will be allowed. This test for zero is what allows 'parent' to dangle harmlessly in some cases.
Definition at line 1185 of file rc.hpp.