Game Programming Gems4 1.7 代码错误

对象生存周期管理是C++工程最重要一个环节。关于此类问题《游戏编程精粹》（GPG）系列一直有文章在提。比如第三册 1.5 《基于句柄的智能指针》，第四册1.7的《弱引用和空对象》。在GPG4 1.7给出的代码中发现了一些问题。原始代码如果放入实际工程结果会很不美妙。这里提一下

原文对指针的包装做如下处理：

template <class ResourceType> class ResPtr
{

public:

     //一些构造函数

    ResPtr(const ResPtr<ResourceType> & resPtr);
    explicit ResPtr(ResourceType * pRes);
    ResPtr(ResourcePtrHolder * pHolder = NULL);

public:

   //析构
    ~ResPtr();

private:

//用这个中间层封装指针
    ResourcePtrHolder * m_pResHolder;
}

class ResourcePtrHolder
{
public:
    ResourcePtrHolder (IResource * p) : pRes(p) {}
    ~ResourcePtrHolder();

//用户对象指针放这里
    IResource * pRes;
};

 

template <class ResourceType> ResPtr<ResourceType>::ResPtr(ResourceType * pRes)
{
    m_pResHolder = new ResourcePtrHolder(pRes); //封装原生指针时，在heap生成一个新ResourcePtrHolder对象
}

template <class ResourceType> ResPtr<ResourceType>::~ResPtr()
{//空析构
}

其他ResPtr代码略，但值得一提的是没有 delete   m_pResHolder  字样...

也就是说假如直接使用ResPtr ，用一次就有一个  ResourcePtrHolder 对象泄露

 

代码提供了另外一套引用计数的指针包装版本，ResourcePtrHolder内使用了delete this 销毁内存。但依然有个问题：

 

ResourcePtrHolder::~ResourcePtrHolder()
{
    delete pRes;
}

首先IResource 对外部要管理的指针类型做出了强制性的规定。必须是从IResource派生的类。其次是在holder析构时，不由分说把一个外部传入要管理的对象指针的内容删除。这样强硬的策略我想无论放到哪里都会导致异常巨大的问题。即便是采用引用计数版本，在holder计数到0再删除自己，顺带删除管理的对象，对于外部来讲也是个黑洞。

 

1.7代码的质量让人惊诧，还不知道整本书有多少类似的

转载于:https://www.cnblogs.com/puzzy3d/archive/2008/07/31/1257085.html