OSG的内存管理策略

OSG和OpenGL的主要区别之一是OSG提供了组织空间场景的功能。OSG把空间场景和场景中的所有物体都组织在一棵树下。根节点代表整个场景，由根节点出发可以遍历场景中的所有物体。这个实现很简单了，如果我是这棵场景树的设计者，首先想到的就是，定义这个的节点类：
class  gNode{
public:
    virtual ~gNode();
    void addChild(gNode*  pChild);
private:
    std::vector<gNode*> m_children;  //存储指向儿子的指针
};
当我做完所有的事情，准备结束程序的时候，我需要释放整个场景树,也很简单啊，看我的
gNode::~gNode()
{
     std::vector<gNode*>::iterator iter;
    for(iter =  m_children.begin();iter!=m_children.end(); iter++)
   {
        if(NULL!=*iter)
       {
            delete  *iter; //如果这个节点还有儿子，会自动递归下去释放的
        }
    }
    m_children.clear();
}
嘿嘿，不错啊，能够完成所有的工作并且没有内存泄露！
可是我们看这样一个问题，假设现在的场景是一个教室，教室中有40张课桌，是一模一样的课桌，整齐的排放成5排8列。那我们的根节点是教室，根节点下面有40个儿子，假设一张课桌由200个三角形组成。那每个课桌节点都保存了这一样的200个三角形，也太浪费了！这样好了，三角形数据不放在课桌节点里面了，我再加一个类专门用来存数据，叫gDeskDataNode.课桌节点里面保存了指向gDeskDataNode的指针：
class  gDeskNode: public gNode
{
public:
    ~gDeskNode(){ if(m_Data) delete  m_Data; }
     void SetDataNode(gDeskDataNode* data){ m_Data = data;  }
private:
     gDeskDataNode*  m_Data;
};
一运行，完了，发现Crash！为什么呢，因为场景根节点下的40个课桌节点是共享同一个数据节点的，但是现有的释放方式却试图去delete 数据节点40次。那也难不倒我，给gDeskDataNode加一个引用计数不就可以了吗？！
class gDeskDataNode:public  gNode
{
public:
    void ref() { m_refCnt ++ ;}
    void unref() {  if(0==–m_refCnt) delete m_Data;}
private:
    ~gDeskDataNode();  //注意，这里我故意把析构函数放在private里面并且没有函数实现，就是为了不让用户显式的delete，或者在栈上定义数据对象
    int  m_refCnt;
};
可是问题又来了，我们一个一个来看：
问题1. 我得为每一个数据节点对象(因为还有椅子节点，黑板节点，窗户节点…)都写一个addRef和releaseRef函数。
解决方案：  我们定义一个叫Reference的基类来管理所有的引用计数，让所有的数据节点都从Reference继承就可以了。

问题2. 要修改SetDataNode和gDeskNode的析构函数
解决方案：
void  gDeskNode::SetDataNode(gDeskDataNode* data)
{
    m_Data = data;
     m_Data->ref();
}
gDeskNode::~gDeskNode()
{
    m_Data->unref();
}
说句实话，这样的实现没有什么太大的问题，但是写得很难看，万一SetDataNode忘记了调用ref呢，还有在SetDataNode的实现很容易让我想起了使用智能指针来解决这个问题，该智能指针的赋值策略是引用计数。
template<class  T>  //T必须是Reference的子类
class ref_ptr
{
    public:
         ref_ptr() : _ptr(0) {}
        ref_ptr(T* ptr) : _ptr(ptr) //构造函数
         {
             if (_ptr) _ptr->ref();//又多了一个使用者，引用计数加一
         }
        ref_ptr(const ref_ptr& rp) : _ptr(rp._ptr) //拷贝构造函数
         {
             if (_ptr) _ptr->ref();//同理，多了一个使用者，引用计数加一
         }

        ~ref_ptr()
        {
             if (_ptr)  _ptr->unref();//少了一个使用者，引用计数减一
             _ptr = 0;
        }

        ref_ptr& operator = (const ref_ptr& rp)  //定义OSG中的智能指针的赋值策略是引用计数
        {
            if (_ptr==rp._ptr) return  *this; //几乎所有的赋值重载在一开始都有这样的判断！
            if(_ptr) _ptr->unref();   //我就要去管理别人了，你自由了
      
            if(_ptr = rp._ptr) _ptr->ref();  //多了一个用户，引用计数加1
            return *this;
        }

        inline ref_ptr& operator = (T* ptr){…}//代码和operator=(const  ref_ptr& rp)基本是一样的
        //模拟普通指针的操作
        T& operator*()  const  { return *_ptr; }
        T* operator->() const { return _ptr;  }
        T* get() const { return _ptr; }
private:
        T*  _ptr;
}；
哈哈，好了，现在gNode可以这样写了(OSG中不但对数据节点采用引用计数的策略，对场景中的实物节点也一样)：
class  gNode: public Rerefence
{
public:
    virtual ~gNode(){};  //注意哦，现在在gNode的析构函数中什么也不需要写了
    void addChild(gNode* child){  m_children.push_back(child);}
private:
    std::vector<  ref_ptr<gNode>> m_children;
}；
gDeskNode可以改成
class gDeskNode:  public gNode
{
public:
    SetDataNode(gDeskDataNode* data) { m_Data =  data;} //看，代码简洁多了
    ~gDeskNode() {}; //不用再调用m_Data->unref()了哦
private:
    ref_ptr<gDeskDataNode>  m_Data;
};
现在看上去很不错了，运行一下也没有问题，但是这个ref_ptr的设计本身是有致命问题的！我们假设（只是假设）有一个节点A，A有一个儿子节点B，现在A和B的引用计数都是1，我写了这样一条语句：
ref_ptr<A>  = ref_ptr<B>  //完了！！
我们来分析一下，按照现有的operator=的代码，首先调用A->unref(),如果这时候A的引用计数降到0，A析构，由于B是A的儿子，B->unref()也会被调用，于是B的引用计数也降到0，B析构。接着代码调用B->ref()试图增加B的引用计数，可是B已经不存在了，ref_ptr<B>中存储的只是一个野指针！
所以，赋值函数应该先  增加待接管资源的引用计数，然后再减少现维护资源的引用计数：
ref_ptr& ref_ptr::operator = (const  ref_ptr& rp)
{
            if (_ptr==rp._ptr) return  *this;
            T* tmp_ptr = _ptr;   //为了后调用现有对象的unref,先暂存现有对象指针
            _ptr = rp._ptr;    
             if (_ptr) _ptr->ref(); //调用待接管对象的ref
            if (tmp_ptr)  tmp_ptr->unref(); //调用暂存对象的unref
            return  *this;
}
现在我们再来分析一下刚才的情况：
首先B->ref()被调用，B的refCnt=2，然后A->unref()，A的refCnt=0,A析构，调用B->unref(),B的refCnt=1,一切都很好！
最后注意一点，OSG中的ref_ptr智能管理堆上分配的对象，不能管理栈上的对象。

 

转载地址： http://blog.csdn.net/arrow_pig/article/details/6123219