FMOD objects are generally acquired from a function or member-function call and released with a call to their "release" member function. It would be extremely helpful if in addition to "release," you also provided "addRef," which internally increments a reference count with the object. This way, "release" only truly destroys and deallocates the object when the internal reference count reaches 0. This functionality is extremely common for object models, including for instance, COM (and in turn, DirectX).

The rationale here is that it is extremely common in object-oriented code to have shared-ownership of objects, implying that objects are often reference counted. The problem is that, because the users themselves aren’t allocating the objects, they can’t directly couple a reference-count with the object during allocation, so if they need to use reference counting, they have to use additional dynamic memory allocation simply to store a reference count. None of this is needed with the simple addition of an "addRef" member function and the only overhead it implies is a simple branch in "release" to determine if the reference count should be decremented or if the object should be deallocated. Again, see COM for an example of this type of interface as it is intrinsic to IUnknown (the base of all COM objects).

Note that this also helps in writing, for instance, very simple, copyable smart pointer templates for dealing with FMOD objects having reference semantics to avoid ever having to manually deal with explicit resource management (as it gets taken care of by RAII).


template< typename FMODType >
class fmod_ptr
explicit fmod_ptr( FMODType* object_init = 0 )
: m_object( object_init ) {}

fmod_ptr( fmod_ptr const& source )
: m_object( source.m_object )
if( m_object ) m_object->addRef();
fmod_ptr* operator =( fmod_ptr const& source )
if( &source != this )
if( m_object ) m_object->release();

  m_object = source.m_object;

  if( m_object ) m_object-&gt;addRef();
return *this;

FMODType& operator () const { return *m_object; }
operator ->() const { return m_object; }
FMODType* get() const { return m_object; }
operator bool() const { return m_object != 0; }
~fmod_ptr() { if( m_object ) m_object->release(); }
FMODType* m_object;

/* Usage: */

fmod_ptr< System > some_function()
/* ... */

// Passes the System object to the caller (reference semantics)
return fmod_ptr< System >( a_raw_system_pointer );

void some_other_function()
fmod_ptr< System > const system = some_function();

/* ... */

// Use it like a regular pointer

// system is implicitly released when it goes out of scope
// because no one else owns it.

Being able to work with FMOD objects like this makes it less error-prone since "release" is called automatically when objects go out of scope and it also makes it both easy and efficient when dealing with, perhaps most notably, storing FMOD objects in STL containers and having the objects automatically managed and exception safe. The simple addition of "addRef" to the different FMOD types goes along way towards making this more feasible. As great as FMOD is, I would love it if it embraced more modern C++ style, as at the moment, it still feels very much like C with classes.

  • You must to post comments
Showing 0 results
Your Answer

Please first to submit.