Cocos2d-x 的内存管理(3)

class _OgreExport FileSystemArchiveFactory : public ArchiveFactory
{
  public:
    virtual ~FileSystemArchiveFactory() {}
    /// @copydoc FactoryObj::getType
    const String& getType(void) const;
    /// @copydoc FactoryObj::createInstance
    Archive *createInstance( const String& name )
    {
      return OGRE_NEW FileSystemArchive(name, "FileSystem");
    }
    /// @copydoc FactoryObj::destroyInstance
    void destroyInstance( Archive* arch) { delete arch; }
};
这里这个FileSystemArchiveFactory就是典型的例子. 虽然这里的destroyInstance仅仅是一个delete, 但是还是这么设计了接口.

单独的缓存
一般而言, 所有与内存管理相关的C语言API设计都应该使用上面提到的两种方案, 其他的方案基本都是错的(或者有问题的), 但是因为各种考虑, 还是有些很少见的设计, 这里把一些可能出现的设计也列出来.
所谓的单独缓存的设计, 指的是一段代码内部的确需要缓存, 但是不由外部传入, 而是自己直接分配, 只是每次的调用都使用这一份缓存, 不再释放.
比如C语言中对错误字符串的处理:

char * strerror ( int errnum );
strerror这个API的设计咋一看就有蹊跷, 什么样的设计能传入一个整数, 然后返回一个字符串呢? 字符串的存储空间哪里来的? 一个简单的例子就能看出这样设计的问题:

#include <stdio.h>
#include <string.h>
#include <errno.h>

int main ()
{
  char *error1 = strerror(EPERM);
  printf ("%s\n", error1);

  char *error2 = strerror(ENOENT);
  printf ("%s\n", error1);
  printf ("%s\n", error2);

  return 0;
}
此时会输出:
Operation not permitted
No such file or directory
No such file or directory

意思就是说, 当第二次调用strerror的时候, 连error1的内容都变了, 对于不明情况的使用者来说, 这绝对是个很意外的情况. 虽然说, 这个例子比较极端, 在错误处理的时候不太可能出现, 但是这种设计带来的问题都是类似的. 至于为什么获得错误字符串的API要做这样的设计, 我就无从得知了, 可能是从易用性出发更多一些吧.

在另外一些基于效率的考虑时, 也可能会使用这样的设计, 我只在一个对效率有极端要求的情况下, 在真实项目环境中见过这样的设计. 那是在做服务器的时候, 一些辅助函数(对收发数据包的处理)需要大的缓存, 同时操作较为频繁并且效率敏感, 才使用了这样的设计.

一般来说, 这种设计常常导致更多的问题, 让你觉得获得的效率提升付出了不值得的代价. 所以除非万一, 并不推荐使用.

我分配, 你负责释放
这种API的唯一好处就是看起来使用较为简单, 但是在任何情况下, 都不仅仅是容易导致更多问题, 这种设计就是问题本身, 几乎只有错误的代码才会使用这样的设计, 起码有以下几个简单的原因:

返回一段buffer的接口, 内部可以使用new, 也可能使用malloc分配, 外部如何决定该使用delete还是free释放, 只能额外说明, 或者看源代码.
当API跨内存空间调用时, 就等于错误, 比如当API在动态库中时. 这是100%的错误, 无论是delete还是free, 也不能释放一个在动态库中分配的内存.