Archon::Utilities::RefObjectBase Struct Reference

Base class for smart pointer objects. More...

#include <archon/util/ref.H>

Inheritance diagram for Archon::Utilities::RefObjectBase:

Inheritance graph
Collaboration diagram for Archon::Utilities::RefObjectBase:

Collaboration graph
List of all members.

Public Member Functions

virtual ~RefObjectBase ()
 Must be virtual for derived destructors to be called.
unsigned long getUseCount () const

Protected Member Functions

 RefObjectBase ()
virtual void refDispose (Mutex::Lock &)
 This method is called when the reference count drops to zero.
unsigned long getUseCountNoLock () const

Detailed Description

Base class for smart pointer objects.

Any class T whos objects are to be referenced by smart pointers Ref<T> must derive from RefObjectBase. This is necessary because it is RefObjectBase that contains the actual usage count and the methods for manipulating it. The manipulation is done automatically and behind the scenes by Ref<T>.

Note: It is normally a good idea to derive virtually from RefObjectBase as this allows you to use multiple inheritance when you build up a hierachies of reference counted objects. An example of this is the X3D node hierachy, A counter example is the stream endpoint objects: ReaderBase and WriterBase. In this case it is important that we get distinct copies of the reference count when we combine them into a BasicPipe.

Note also that, unless you overide the 'dispose' method to something that never deletes, you must always ue dynamic allocation for the classes derived from RefObjectBase. Never use automatic objects on the stack and do not make them members of other classes.

See also:


Definition at line 423 of file ref.H.

Member Function Documentation

void Archon::Utilities::RefObjectBase::refDispose Mutex::Lock  )  [inline, protected, virtual]

This method is called when the reference count drops to zero.

Normally this implies that the object must be deleted and therefore this is also the default action for this method.

You may override this in your derived classes, and normally you will want to do this if the time of destruction is determined not only by the reference count. A good example of this is the BasicPipe template which involves two distinct reference counts. Only when both have reached zero the pipe should be destroyed.

This method is always called with a lock on the mutex. this is to allow overriding methods to consistently check the state of the object before determining whether it should be deleted. However it is an error to delete the object while a lock is held. Therefore the lock is passed as an argument.

See also:

Reimplemented in Archon::Utilities::Stream::BasicPipe< C >, Archon::Utilities::BackRefObjectBase, Archon::Utilities::Web::DefaultResponse, Archon::X3D::SAI::ExternalRoute, Archon::X3D::Route, and Archon::Utilities::Stream::BasicPipe< char >.

Definition at line 1048 of file ref.H.

References Archon::Utilities::Mutex::Lock::release().

The documentation for this struct was generated from the following file:
Generated on Sun Jul 30 22:57:52 2006 for Archon by  doxygen 1.4.4