在做一个纯类声明时，例如

class A；

以后的应用，仅限于声明指针，任何包含实际意义的操作，比如调用其下函数和内存分配，都是不允许的

这几天因为设计上得需要，突然想起用成员函数指针，老实说，基本上没有用过这个，以前都是用函数指针来做回调函数得，所以第一次使用发生了许多问题。

    具体测试代码如下：

#include <iostream>

using namespace std;

class TestA
{
public:
TestA(int a) {m_test = a;}
void test()
{
  cout<<"A的实例打印测试"<<m_test<<endl;
}
int m_test;
};

struct C {
typedef void (C::*pFunc)();
pFunc funcArray[2];
void func1(){}
void func2(){}
C() {
  funcArray[0] = &C::func1;
  funcArray[1] = &C::func2;
}
void func3() {
  (this->* funcArray[0])();
}
};

typedef void (TestA::*MEMBERFUNC)();

class TestB
{
public:
MEMBERFUNC m_pfn;
TestB()
{
  //MEMBERFUNC m_pfn = &TestA::test;
}

void testB()
{
  //m_pfn = &(ptr_a->test);
  (ptr_a->*m_pfn)();
}

TestA* ptr_a;

};

int main()
{
TestA a(0);
TestB b;
TestA c(1);

b.ptr_a = &a;
b.m_pfn = &TestA::test;
b.testB();
system("PAUSE");
}

我原本意图将B类得成员函数指针中保存指向A类得成员函数，但是编译老是出错。查看了MSDN相关得内容和网上一些关于使用成员函数指针得文档后，改成如上得样子。

具体得问题在于成员函数指针必须动态得绑定到具体类实例

因此在B类中声明A类成员函数得成员函数指针变量时，形式如typedef void (A::*func)();

这样得声明在，调用时，因为B类中会传默认得this指针，就成为了B::func，所以无法调用成功，必须在->操作符前指明指向A得指针，我因此加了ptr_a;

但这样一来，我觉得不如直接在B类中保存A类指针，那还需要用成员函数指针吗，白白增加了复杂度

通过几个MSDN例子，发现成员函数指针多用在指向自己本身得成员函数

这样看来，只有在同类，不同实例互相调用时使用会比较方便了，否则貌似没必要，大概这也是为什么它得使用不及函数指针吧

在研究了目前项目使用的内存分配方式和HAVOK的内存分配方式后，发现：

我们的项目中使用的并非是基于帧的内存分配方式，而是一种很接近于帧的内存分配的方式。和大多数的游戏一样，我们使用自己的内存分配和释放函数（通过对new和delete的重载）。这里先要谈论的是在游戏中的内存管理

游戏中之所以不采用系统标准的内存管理函数，其原因是从效率上考虑的。而采用系统标准的内存管理函数的话，第一是容易产生内存碎片，第二无法添加对内存进行监控和调试的信息，第三，无法将物理内存映射为连续的逻辑内存。

为了解决以上问题（参考Game Gem1中的主要矛盾为内存碎片），发明了基于帧的内存分配方式。“帧”在这里的概念我个人理解为一个节点，而非通常意义上的视频概念里的一帧，也不是Game Gem中解释的句柄（句柄这东西实在不好理解，老手当然懂了，我觉得还是解释为节点一目了然）。所谓的“节点”就是保存对于一个特定时间点上内存操作的信息。比如什么时候分配了内存，分配了多少，什么时候释放了内存等

在基于帧的内存分配里，帧就是保存内存分配时，申请到的内存地址。比如你执行一次new，返回一个0xADD1的地址，在执行一次，返回0xADD2，那么这是我们有一个struct来保存这两个指针，也就是形成了两个帧

基于帧的内存分配的思想是，事先划分一块较大的内存供日后申请，每次申请保存帧信息。并且内存分配采用类似堆栈的方式，也就是先进后出（采用堆栈，我认为是由内存工作方式，和汇编指令工作方式造成的，先占领地位内存地址）

在保存完帧信息后，无论我们对接下来的地址如果做分配，释放。只要在回收该块内存后，使用帧信息就不会产生碎片，比如：帧中记录内存地址为0x00001111，然后对起始地址后的4K空间进行分配，第一次分配结构structA的数组，大小为24B，第二次分配结构structB的数组，数组元素大小37B，这样类似大小不一就容易产生碎片，但如果我们始终按照0x00001111的地址释放其后面的空间，就可以把碎片回收，同时反复使用了我们预先分配的内存

目前，我们的项目中是采用链表方式来完成这一功能，虽然也做到了反复利用预先申请的内存，也使用链表的后向指针来保存了类似帧的信息，但是我们采用判断申请内存是否大于现有Free块，才决定是否分配，所以如果申请内存总是比free块小一点，是会产生碎片的

在HAVOK中的基于堆栈的内存分配，在释放时，将一次性释放其后所有内存地址。同时在一些havok中的步进运算中，确实可以采用先进后出的方式来抛弃指定帧后的无用数据，加快速度和内存使用效率。

即使，在局部方法中，由系统分配堆栈，但是可能UNIX和WINDOW等操作系统将消耗额外CPU时间在逻辑上组合一块连续内存，而对于一些游戏机上无此类高级内存管理功能的情况，有可能就无法请求比较大的内存块。因为我们构建预先使用的一块堆栈用内存，并提供申请释放方式。当在局部方法中使用时，来代替系统分配的堆栈，并在方法结束时释放堆栈，就解决了以上问题。