irrlicht引擎源码剖析3 - 引用计数

在研究irrlicht的video driver和scene graph之前，必须先了解在irrlicht中广泛应用的引用计数机制。irrlicht的接口IReferenceCounted实现了引用计数的机制。需要采用引用计数管理的类都会继承这个接口。irr的引用计数最重要的两个接口就是grab()和drop()。

 

bool drop() const{// someone is doing bad reference counting._IRR_DEBUG_BREAK_IF(ReferenceCounter <= 0)--ReferenceCounter;if (!ReferenceCounter){delete this;return true;}return false;}

grab()只是简单的将引用计数加一，而drop()是这个机制的核心，当drop()后当引用计数为0时，对象实例通过delete this删除自己从而最终释放了无人再使用的对象。正确的使用grab()和drop()是引用计数机制的核心，当你想长期持有一个对象时，需要grab()他，然后在不再使用的时候drop()他。grab()后，这个对象就不会因为其他地方的drop而被释放掉，因为至少你还有对他的引用。如果只是在一个函数段里面短期的使用一个对象，可以不grab也不drop，当然你要考虑多线程的情况。另外如果对象是你创建的，但你不能决定什么时候释放他，你就应该再把该对象添加到某个对象后调用drop(),这种情况也很常用。比如下面的伪代码：

IImage* pImage = new CImage(...);

pImageManager->add(pImage); //in add, pImageManager will call a grab()

pImage->drop();

这样很容易将对象的创建和释放分开到不同的对象中。

当然引用计数机制也让很多人讨厌，因为用乱了用错了麻烦一大堆。如果是自己创建的对象还好，而irrlicht引擎中提供的对象就要小心对待了。一般说来使用getXXX()得到的对象不需要drop(),当然除非你grab()了。使用createXXX()或你自己new出来的对象，你需要保证他在某个地方被drop()了，实在不放心应该深入引擎的代码看一下，建议使用vld这样的可视化内存泄露监测工具帮助你查找泄露内存的地方。

 

另外还有两个值得注意的问题

1）IReferenceCounted接口往往是被虚拟继承的，例如

class ISceneManager : public virtual IReferenceCounted

因为使用引用计数的接口和类很多，有可能某个类实现了几个接口，而这几个接口都继承自IReferenceCounted, public virtual继承保证只有一个IReferenceCounted基类对象

例如class CSceneManager : public ISceneManager, public ISceneNode就是这种情况

因为：

class ISceneNode : virtual public io::IAttributeExchangingObject

class IAttributeExchangingObject : virtual public IReferenceCounted

而class ISceneManager : public virtual IReferenceCounted

 

2）观察一些irrlicht引擎中的接口,接口中没有定义虚拟的析构函数

例如class IMesh : public virtual IReferenceCounted，在include/IMesh.h中

这个接口里面连~IMesh()都没有，更不会有virtual ~IMesh()了。

按照c++通常的思维，如果一个类明确的是要被继承的，需要定义一个virtual析构。那么为什么irrlicht中的很多接口都不定义呢？正因为他是引用计数的。比如，有一个接口IBase和他的子类CDerived。如果这么用

IBase* pBase = new CDerived();

那么当delete pBase时，如果IBase没有虚拟析构，就不会正确执行CDerived的析构了。

但是如果IBase继承自IReferenceCounted，通常我们的用法不会使用delete pBase来释放这个对象了。我们会使用pBase->drop(),问题就在这儿，这个drop()就是IReferenceCounted接口定义的那个，最终会执行delete this,这个this的类型就是调用drop()的对象的类型，这个对象实际是子类的，所以会调用子类的析构函数，从而会进一步调用父类的析构，所以父类没有定义虚拟析构也不要紧了。这就是引用计数的花招。当然irrlicht引擎中有些接口也定义了虚拟析构，这没有影响，这样更安全，即使某人没有用引用计数的方法管理对象的生命周期也不会出问题。我觉得，无论是否使用这样的引用计数机制，最好给父类都加上虚拟析构比较安全，也比较明确。