在研究irrlicht的video driver和scene graph之前,必须先了解在irrlicht中广泛应用的引用计数机制。irrlicht的接口IReferenceCounted实现了引用计数的机制。需要采用引用计数管理的类都会继承这个接口。irr的引用计数最重要的两个接口就是grab()和drop()。
view plaincopy to clipboardprint?
bool drop() const
{
// someone is doing bad reference counting.
_IRR_DEBUG_BREAK_IF(ReferenceCounter <= 0)
--ReferenceCounter;
if (!ReferenceCounter)
{
delete this;
return true;
}
return false;
}
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引擎中有些接口也定义了虚拟析构,这没有影响,这样更安全,即使某人没有用引用计数的方法管理对象的生命周期也不会出问题。我觉得,无论是否使用这样的引用计数机制,最好给父类都加上虚拟析构比较安全,也比较明确。
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/n5/archive/2009/07/12/4342758.aspx