StrongPtr Ownership policies
Collaboration diagram for StrongPtr Ownership policies:
- These terms are used within this file's comments.
- StrongPtr : Class used to implement both strong and weak pointers. The second template parameter determines if a StrongPtr is weak or strong.
- Strong pointer : A pointer that claims ownership of a shared object. When the last strong copointer dies, the object is destroyed even if there are weak copointers.
- Weak pointer : A pointer that does not own the shared object it points to. It only destroys the shared object if there no strong copointers exist when it dies.
- Copointers : All the pointers that refer to the same shared object. The copointers must have the same ownership policy, but the other policies may be different.
- Pointee : The shared object.
- The ownership policy has the pointer to the actual object, and it also keeps track of the strong and weak copointers so that it can know if any strong copointers remain. The plain pointer it maintains is stored as a void pointer, which allows the ownership policy classes to be monolithic classes instead of template classes. As monolithic classes, they reduce amount of code-bloat.
- Writing Your Own OwnershipPolicy
- If you write your own policy, you must implement these 12 functions:
- explicit YourPolicy( bool strong )
- YourPolicy( void * p, bool strong )
- YourPolicy( const YourPolicy & rhs, bool strong )
- bool Release( bool strong )
- void Increment( bool strong )
- bool Decrement( bool strong )
- bool HasStrongPointer( void ) const
- void Swap( YourPolicy & rhs )
- void SetPointer( void * p )
- void ZapPointer( void )
- void * GetPointer( void ) const
- void * & GetPointerRef( void ) const It is strongly recommended that all 12 of these functions be protected instead of public. These two functions are optional for single-threaded policies, but required for multi-threaded policies:
- void Lock( void ) const
- void Unlock( void ) const This function is entirely optional:
- bool Merge( TwoRefLinks & rhs )
- The delete policy provides a mechanism to destroy an object and a default value for an uninitialized pointer. You can override this policy with your own when using the Singleton, NullObject, or Prototype design patterns.
- Writing Your Own DeletePolicy
- If you write your own policy, you must implement these 3 functions:
- void static Delete( const P * p )
- static P * Default( void )
- void Swap( YourResetPolicy & )
- A reset policy tells the ReleaseAll and ResetAll functions whether they should release or reset the StrongPtr copointers. These functions do not affect just one StrongPtr, but all copointers. That is unlike SmartPtr where the Release and Reset functions only affect 1 SmartPtr, and leave all copointers untouched. A useful trick you can do with the ResetPolicy is to not allow reset when a strong pointer exists, and then use the NoCheck policy for all strong pointers. The reset policy guarantees the strong pointers always have a valid pointee, so checking is not required; but weak pointers may still require checking.
- Writing Your Own ResetPolicy
- If you write your own policy, you must implement these 2 functions:
- bool OnReleaseAll( bool ) const
- bool OnResetAll( bool ) const The bool parameter means that this was called with a strong pointer or one of its copointers is strong. The return value means the pointer can be reset or released.
Generated on Sun Feb 25 16:52:30 2007 for Loki by