包含<sstream>，顺便加个使用名字空间std的声明，可以开始了。sstream里包括istringstream、ostringstream、stringstream、stringbuf和各宽字符版本的对象类型。更方便的格式化字符串处理，更安全的类型转换。

这天还是要做那个机器视觉的编程实验，涉及不少数据的提取和保存。也就是"硬盘文件->内存数据"、"内存数据->硬盘文件"这类IO。对我来说，一般会使用的是C时代的FILE* - fprintf - sprintf - sscanf - fread/fwrite，或者C++的fstream - read/write之类的，保存到文件的操作比较简单，那么就来说从文件读入数据了：

2	45.3	68.2	36.8
7	77.4	55.7	70.1
3	22.0	79.9	53.5
...	...	...	...

这样的文件，以前我常常这样做：

	char Buffer[50] = {0};	ifstream infile;    //ifstream infile(filename);	infile.open(filename, ios::in);  //	int DATA1;	float DATA2, DATA3, DATA4;	char c;	while(infile.get(c))	{		if(c==0x00 || c == '\n'  || c =='\t')continue;		else		{		infile.seekg(-1, ios::cur);		infile.getline(Buffer, 50);		sscanf(Buffer, "%d  %f %f %f ",		&DATA1, &DATA2, &DATA3, &DATA4);        DATA1list.push_back(DATA1);         DATA2list.push_back(DATA2);         DATA3list.push_back(DATA3);         DATA4list.push_back(DATA4);		}	}	infile.close();

基本上就是字面的意思。但是，这个样子经常会出错，特别是格式化字符那里，又有多少人铭记double类型的格式化字符是%lf而不是%f呢……用sstream，就可以这样做：

//ifstream infile;    infile.open(filename, ios::in); 	int DATA1;	float DATA2, DATA3, DATA4;	stringstream sem;	sem << infile.rdbuf();	  while(true)	  {		sem >> DATA1;		if(sem.eof())break;		sem >> DATA2;		sem >> DATA3;		sem >> DATA4;		DATA1list.push_back(DATA1);		DATA2list.push_back(DATA2);		DATA3list.push_back(DATA3);		DATA4list.push_back(DATA4);	  }infile.close();

1. fstream对象的rdbuf()成员函数返回的是一个std::filebuf*指针，用以重定向流，结果就是文件的内容全部作为一个C++流，流向我们的stringstream对象里。

2.我们从该stringstream对象里从头取出各个数据到中间变量DATAi中，这可不是一个一个字符取哦，因为它是以空格或者\n,\t之类字符为分隔的，所以很方便；

3.同时，这里取出到DATA的也不是字符串，而确实就是连续一个int三个float哦，因为内部有安全的转换机制，所以不要再担心C那种格式化的问题了，无论是INT还是DOUBLE还是CHAR*都能做到。这是stringstream最强大之处。

4.判断“取”的动作结束的eof()为什么要在最后做了一次“无用功”后才判断呢？因为只有这样能判断。stringstream这时候扮演着一个乐施者，他不会去数自己包包里还剩下多少块波板糖，只会不停伸手入包里取出糖，而只有最后一次伸手入包包发现已经没糖了——所以才叫最后一次——才会醒觉：哦，原来我一贫如洗了。

基本上太强了。再举例，这次是保存数据到文件，虽是简单，但如果按我以前用fstream文件流的方法，效果比C的fwrite要糟糕：

	char Buffer[50] = {0};	ofstream fileSave;    fileSave.open(filename,ios::ate);	for(int i = 0 ; i < Num; i++)	{	 sprintf(Buffer, "%d  %.2f %.2f %.2f ",	DATA1[i], DATA2[i], DATA3[i], DATA4[i]);	 fileSave.write(Buffer,sizeof("00  00.00 00.00 00.00"));	}	  fileSave.close;

问题在sizeof("00  00.00 00.00 00.00")这里，我没办法确定真实数据的大小。事实上原始数据某组是（3 21.52 63.31 22.22 1.36）或者（320 25.36 54.322 72.31 32.101）都会很麻烦——一般是尽量让这个size大点，不要让它把后面的吃了，但过小的话后面就会出现其他多余的字符，或者每组数据不对齐造成文件不雅观(用strlen()就是另话了)。用stringstream的话，我只想说：很文雅：

//   ofstream fileSave;    fileSave.open(filename,ios::ate); 	ostringstream strStream;	strStream.setf(ios::showpoint);	strStream << std::setprecision(4);   for(int i = 0 ; i < Num; i++)   {      strStream<<DATA1[i]<<"  " <<DATA2[i]<< "  "<<DATA3[i]<< "  "<<DATA4[i]<<endl;      fileSave.write( strStream.str().c_str(), strStream.str().size() );  }  fileSave.close;

setprecision(4)是有效数字位数，所以数据不会难看（当然小数位数也是可设定的），配合strStream<<DATA1[i]<<"  " ……这样的“流”式输出，感觉太好了。最后write的参数就是strStream内容转为std::string后，其大小以及再转化为char*所得的底层字符串地址了。太好了。

我不太研究STD里的效率问题，所以我不能给出效率方面的建议，但是，即使效率有小小损失，抵得过它的方便吗？以前基本用fprint,sscanf现在想多用stringstream了；以前是char*用得多、MFC也用CString，但现在觉得标准C++的string其实也很可爱的；以前是atoi,atof，然后sprintf做f-to-char,i-to-char(a)，现在知道stringstream才是这类转换的高手哈。

最后提下，清空一个stringstream对象(stringstream strs)里的内容时，单strs.clear()是不行的，要用strs.str("")这句才行哦。最后最后，写程序时写出的一段代码，给有缘人参考，多多指教：

//把整个文件内容存储到单独一个字符串里：     ofstream dfileSave;     stringstream outstream;       dfileSave.open("tResult.txt",  ios::in | ios::app);       std::filebuf *pFileBuffer =  dfileSave.rdbuf();       outstream << pFileBuffer;       int filesize = pFileBuffer->pubseekoff(0, ios::end, ios::in);       std::string sre = outstream.str(); //1     const char *de = sre.c_str();  //2       dfileSave.close(); //ZwqXin: 拜拜~！

有这么一个库，库里有个工具类，不妨认为是一个关于listbox操作的类吧（事实上就是了- -）。它通过头文件提供接口给我们使用，而把实现藏进dll里面了(或者是lib里面)。这个类有个特点：除了构造析构函数之外的都是纯虚函数。也就是说，这完全就是一个“接口(interface)”概念的类。

纯虚函数的概念就不多解释了。它的代名词就是“抽象”，尽管你不一定认为它有多么需要抽象。

现在，我觉得这个工具类（姑且叫BaseListBox）不够用，想从中派生出一个更有内涵的子类（不妨叫DerivedListBox）。问题来了，这不是MFC，没有像MFC那样预先考虑让人随便重载界面类。面对这个完全“虚”了的BaseListBox，我能想到的重载方式——没啥，把这些函数全部“重载”吧。

class BaseListBox
{
public:
   BaseListBox(){}

   virtual void func1()=0;
   virtual void func2()=0;
};

class DerivedListBox : public BaseListBox
{
public:
   DerivedListBox() : BaseListBox(){}

  void NewFunc(){} 
 
   virtual void func1(){};
   virtual void func2(){};
}

实际上该工具类也没成员函数，因此用的是默认析构(因为它也是继承来的,这个与本主题无关,就不待多言了，但继承体系的底部有个虚函数析构是时刻有必要提醒的)。 ~简化一下，用上面的代码说明问题好了。当然，事实上这种funX()的函数有N个....

如何维护“子类就是父类”这个说法呢？在代码部分变通一下：

class DerivedListBox  :  public BaseListBox
{ 
public: 
   DerivedListBox() : BaseListBox(){} 

  void NewFunc(){}  
  
   virtual void func1(){ return BaseListBox::func1() }; 
   virtual void func2(){ return BaseListBox::func2() }; 
}

啥米？调用父类的纯虚函数？！那不是纯虚函数吗？那不是接口吗？呃....没什么好惊奇的。原来的类能给你用，就说明了这些接口真的有代码实现部分。（至于原来是怎么被用的，自个儿想想猜猜吧。）不过这段实现不能用于继承体系，注定了与动态调用无缘。在这里funX函数通过静态方式调用了父类的同名纯虚函数，驶离了“无法实例化”的魔咒。BaseListBox作为“限定符”意味着“要调用的的确就是BaseListBox的那个funcX”，如同通过场景唯一的ID访问场景节点对象[访问游戏怪物]，没有什么可以作为意外的。

所以，注意，C++里纯虚函数也可以有默认实现！

但是，VS2005里抛出了这种链接错误：

 error LNK2001: 无法解析的外部符号 "public: virtual void__thiscall BaseListBox::func1() "

(?.......@@UBEPB_WI@Z).........fatal error LNK1120: 1 个无法解析的外部命令

——ZwqXin.com

改为((BaseListBox*)this)->func1()倒是过了链接，但是同样是运行终止的。

无理解错的话，应该是因为编译器找不到该BaseListBox::func1()的实现（默认纯虚实现部分）。链接DLL什么的我真是云里雾里，不过反正就是“无法找到”（或者说“不认为找到了”更合适）。我简单地做过实验，如果BaseListBox的实现是确实在一个实现文件(.cpp)里的话，确实上面这样的代码是能够编译和运行的。

在[C++语言相关]为什么需要工厂(Factory)一文中，根据作者所言，大概也知道在类库里面接口和实现有可能不是那么简单地相连的，编译器说“不认识”自然有它的苦衷，我不认为这次也是因为它坏掉了。（好心人可详细解释一下吗？）

因此，有个折中的坏主意：

class BaseListBox 
{ 
public: 
   BaseListBox(){} 

   virtual void func1()=0; 
   virtual void func2()=0; 
}; 

class DerivedListBox : public BaseListBox 
{ 
public: 
   DerivedListBox(BaseListBox  *listbox)
     : baseListbox(listbox),  BaseListBox(){} 

  void NewFunc(){}  
  
   virtual void func1(){ baseListbox-> func1() }; 
   virtual void func2(){ baseListbox-> func2() }; 

private:
   BaseListBox  *baseListbox;
}

这种手法的重点应该落在baseListbox这个成员指针的“值”之问题上。的确，库里面BaseListBox本来就不是为了作为基类而使用的（或者我改回IListBox更不容易招见误会），库通过其他手段能直接创建一个真正的ListBox界面控件，返回其BaseListBox*指针。（或许前面的错误与此也有关。）这样，通过DerivedListBox的构造函数传入此指针后，就如同DerivedListBox 作为一个可装单一物件的容器与BaseListBox关联。这样一来，其实继承也没什么用处了。

或许改名IListBoxContainer更适合，但是我仍然想让该DerivedListBox像一个真正的“Derived-ListBox ”，于是把BaseListBox里面的纯虚函数都通过这种“呼叫”的方式，在每个同名函数里通过BaseListBox*指针调用。不抹去“: public BaseListBox  ”也是为了让继承体系更底端的函数也“有效”。

int main()
{
//必须有种能产生有效BaseListBox指针的方式
 BaseListBox *olistbox = xx->createyy();

  DerivedListBox *listbox = new DerivedListBox (olistbox );

  listbox->func1();
  listbox->func2();
  listbox->NewFunc();

return false;
}

总之，在一定场合这种坏主意还是能帮忙的。

感谢你的指导与收看，这里是ZwqXin的3D编程事件记录簿，谢谢莅临，意见可在本页面评论或光临舍下的留言簿。

阁下对此问题有更好的处理方式吗？可否不吝口水告之呢？

1.不要怕使用全局变量

貌似效率更高？可是......可是........好吧，真不知谁说得对。我最初的OpenGL程序其实是用纯粹C编写的，说纯粹C貌似不好吧（我对C之精髓真是...恩，遥望），过程式结构吧。过程式就算了，还一直只会用全局变量...（原谅我吧，当时连“类”是啥米都不知道，虽然一直用的框架的CMainFrame就是一个类 - -）。这或许受点NEHE的初级教程例程的影响（喂，别推卸责任喔~），倒是，为何NEHE不用类封装呢？搞那么多全局函数。学C++后回头看它，以为是为了方便（OpenGL例程嘛，又不是C++例程~~），看来是不是NEHE大师也跟本书作者领悟一样呢？

恩....反正我被PI后，也很少胆敢用全局变量了（倒是有时候随便设些测试用的变量，用完也就删了...），当然，事有必须的 时候...我还喜欢用全局函数全局类呢....唉不多说了。

2.使用内联函数

这个....我也时常用呢。尤其看了Effective C++之后.但是权衡起得失来也经常有"犹豫不决"的时候.反正如果实现太长我就不敢内联了。

3.尽量使用32位变量，而不用8位16位的

唉，可能日后要改成“尽量使用64位变量”呢，谁知道呢。提倡用32位变量是原于内存中存储数据的“对齐”问题，Effective C++在条款50左右也提过，不过那是另一回事了。Pentium处理器全是32位的，意味它不喜欢非32位的（喂，现在呢~），寻址的不规则可能会影响效率。书中举例了：

struct CPOINT
{
short x,y;
unsigned char c;
}
struct CPOINT
{
int x,y;
int c;
}

或许你会抱同样的看法：下面的比较好。完全是因为审美观问题。但是问及效率，我还真答不上来（另外，我也忘记一个short究竟占多少位了 - -）。上面的CPOINT共占（ 2*sizeof(short)+sizeof(char)=）5字节。不要说2的某次方了，还是个奇数......立正！对齐！向前看！

然后作者告诉最后填充一下自定义的结构为32字节的倍数........晕。

4.注释代码

好，灰常好。可惜某Zwqxin是个不好的孩子。

5.RISC尽量简化代码

通常来说，我也不喜欢一行里充满复合指令。也是的，何必为难编译器呢（虽然它是微软的东东！）......好处：方便设置断点（非常“有用”的好处）！让处理器有机会用更多执行单元并行处理更多的代码！

6.使用二进制移位运算来进行乘数，除数为2的简单乘除法

呃....这个...考虑....考虑.........永远地考虑ING呵呵

7.设计高效率算法

“更好的做法是使用清楚、高效率的算法而不是蛮力和穷举型的算法。”（碎碎念：要是上苍公平点人人都有这样的能力这样的头脑，谁不用呢！）

8.不要在编程过程中优化代码（否则就通常是在浪费时间），建议留后完成

虽然深感同意，但是自问自己也没啥“在编码过程中就优化”的能耐......注意，要日后还能看明白自己写的是啥，代码起码写的时候要条理清晰哦。

9.不要为简单的对象定义太多复杂的数据结构

这个....貌似我对数据结构就是蒙....

10.简单而直观的代码是最好的程序

设计模式迷哥迷姐（？）们快去轰他，哈哈，作者叫Andre LaMothe，邮箱ceo@xgames3d.com（被爆了没？）

11.避免一错再错，沿着死路走

这是很好的忠告。但是，如果能告诉我判断怎样的路是死路的方法就更好了。

12.经常备份你的工作

这是很必要的嘛。自己深有同感，有时候就是想回到走错路之前那一步，可惜再回去之前，眼前的这程序却玩起了崩溃。况且备份一次代价太高了TAT，珍惜硬盘呀TAT（摊手：给一个能够一键备份程序必要文件的东东我吧~~）；再况且，CODER不是都不太喜欢“重复的代码”么呵呵。

13.开始工作前，进行一下组织工作，使用合理的文件名目录名，提出一致的名民约定。资源分目录。

好了。第一章，“血海乌鸦”就是这样。其余的....没什么了吧？

参考：WINDOWS游戏编程大师技巧 2nd edition

最早接触设计模式是通过国内那本《大话设计模式》吧，通俗易懂地介绍了GOF的23个经典设计模式，可是我看后就忘了TAT，归根还是实践太少。BOB大叔此书讲述的模式不全，而且杂七杂八的也有些在世界领域少言及（乃至我甚至有时认为是不是大叔原创的- -），但是模式的讲述间传递着这么个思想：咱们模式不是本书主角。的确，模式通常只为了传递软件设计思想，而其本身不想成为思想——每本关于设计模式的书籍的作者大概也时不时在书中提及一下这种理念，但他们明显只是为了洗清自己对读者错误引导的嫌疑而已。《敏捷软件开发》一书中的模式只是为了给之后的案例做准备，它不关于设计模式因此无义务给你详解一个一个的模式。但相信读完此书后，你能谅解模式，你不再把它当作明星，而可能是当作朋友。

设计模式之观察者(Observer)一章是我到现在为止所见的最真诚的设计模式介绍。从一个设计任务开始，思考，重构，最后成其模式。就结果来说我相信是观察者模式的样式中最简单的，简单到可以让人直观其本质，当然这多得BOB大叔的耐心讲解。好了，来看看我看书后顿生的歪主意：

一场射击比赛中，观众霸好头位，准备为他们相中的设射击手呐喊助威。于是，我想到了一个射击手类（shooter）和一个观众类（Audience）。故事围绕一个射击手和三名观众。我假设射击手射中与否是随机事件，用随机函数rand()来决定两种状态。shoot行为引发状态的改变附加一句射击手的胡言乱语，观众看到射击结果后作出反应：

#include "stdafx.h"
#include <cstdlib>
#include "windows.h"

class Shooter
{
private:
	enum{BINGO, TAT};
	int state;
public:
	Shooter(){state = TAT; };
	void Shoot(int random)
	{
		if(random%2 == 0){state = BINGO; printf("射手：好野！打中了！\n"); }
		else {state = TAT; printf("射手：5555！打不中！\n"); }
	}
	int GetState(){return state;}
};

class Audience
{
private:
	enum{WOW, DAMN};
	int state;
public:
                   Audience(int _state){ state = _state; }
	void Reaction()
	{
		if(state == DAMN){ printf("观众：咦~~有无搞错啊，甘都打5中~~~食sh*t啦你~\n\n"); }
        else if(state == WOW){printf("观众：哇，打中了！好犀利啊~~~奖旧sh*t比你食喇~\n\n"); }
	}

};

int main(int argc, char* argv[])
{
	srand(GetTickCount());

	Shooter shooter;
    shooter.Shoot(rand());

	Audience audience(shooter.GetState());
	audience.Reaction();

   shooter.Shoot(rand());
	Audience audience2(shooter.GetState());
	audience2.Reaction();

   shooter.Shoot(rand());
	Audience audience3(shooter.GetState());
	audience3.Reaction();
	
	return 0;
}

注意，在main引导的三次射击中，观众1，2，3分别发表了“评论”，他们必须先从这个shooter的GetState()方法中得知射击结果。

然而，为了不影响射击手的情绪，比赛决定在一个对外封闭的场馆里进行（那观众还来干啥！？），观众怎么知道赛况？怎么联系两者？我忽略公告板的存在，于是我采用BOB大叔给的建议：由射击手发出结果信息，观众将实时接收信息作出反应。先看看main函数的改变：

int main(int argc, char* argv[])
{
	srand(GetTickCount());

	Shooter shooter;//有一个射击手
	Audience audience1(1,&shooter);//3个观众想关注这个射击手
	Audience audience2(2,&shooter);
	Audience audience3(3,&shooter);

//设定:射击手要把结果通知这3个观众
    shooter.registerObserver(audience1);     
    shooter.registerObserver(audience2);
    shooter.registerObserver(audience3);

    shooter.Shoot(rand());//射手照常射击，观众会自动获知结果
    shooter.Shoot(rand());
    shooter.Shoot(rand());
	
	return 0;
}

你可以发现最大的不同在于关键字“自动”。registerObserver是为了映射这种自动通知关系的。在这里,射击手扮演了这个故事的主角——行动表演者（performer），而三个观众扮演了旁观者，也就是“观察者”（observer）。因为我用的是较简单的“拉”模型，因此观众同样是需要获得射手的射击情况（状态）的（与此相对，“推”模型里射击手主动把结果告知观察者），但这次不同的是行动被内化了——就测试代码表层来说，只要射击手“同意”把该观众作为自己的“通知”对象，该观众就有资格获得射击手射击成败的信息。接下来射击手只管射击和自我咏叹（Shoot方法），而观众“自动”作出反应。

首先，抽象出双方的接口，然后，Subject类维护了一个名单，也就是针对某射击手的观察者名单，具有注册和通知功能（这是最基本的，可自加其他功能，譬如移除等），registerObserver把一个新的观察者引用加入通知列表，notifyObserver() 引起各个注册者的行动。

class Performer
{
public:
	virtual ~Performer(){};
	virtual int GetState() = 0;
};

class Observer
{
public:
	virtual ~Observer(){};
	virtual void Reaction() = 0;	
};

class Subject
{
private:
	std::vector<Observer*> ObserverVessel;
public:
	virtual void notifyObserver()
	{
		for(std::vector<Observer*>::iterator p = ObserverVessel.begin(); p!= ObserverVessel.end(); p++)
			(*p)->Reaction();
	}

	virtual void registerObserver(Observer &newobsever)
	{
      ObserverVessel.push_back(&newobsever);
	}

};

显然，名单归射击手所有，因此接下来Shooter要扮演这个Subject的角色，同时也作为行动者。因为BOB大叔的那代码是JAVA写的，我不知道C++怎么处理JAVA和C#里那种“既继承某接口又implement某类”的表达方式，能想到的只有多继承了，抱歉。注意，简单起见，我仅规定Audience类接受单一关注者（myperformer），并把该被关注者（也就是射手）的射击状态关联观众的状态（“拉”模型）：

class Shooter : public Performer, public Subject
{
private:
	enum{BINGO, TAT};
	int state;
public:
	Shooter(){state = TAT; };

	void Shoot(int random)
	{
		if(random%2 == 0){state = BINGO; printf("\n射手：好野！打中了！\n"); }
		else if(random%2 == 1){state = TAT; printf("\n射手：5555！打不中！\n"); }
		notifyObserver();
	}
	virtual int GetState(){return state;}
};

class Audience : public Observer
{
private:
	enum{WOW, DAMN};
	Performer *myperformer;
    int audince_ID;
	int state;
public:
    Audience(int audince_id, Performer *_performer)
		:audince_ID(audince_id), myperformer(_performer)
	{}

	virtual void Reaction()
	{
		state = myperformer->GetState();
		if(state == DAMN){ printf("观众%d：咦~~有无搞错啊，甘都打5中~~~食sh*t啦你~\n", audince_ID); }
        else if(state == WOW){printf("观众%d：哇，打中了！好犀利啊~~~奖旧sh*t比你食喇~\n", audince_ID); }
	}
};

当然，以上只是设计模式之观察者(Observer)的最简单应用，但希望能让看官稍微感受它的思想。恩，它不是公式，而是软件设计思想——这种思想我谓之“伺机而动”。

以上歪主意的代码：ObserverTest.rar

事情是这样的。我今天把CSM(Cascading Shadow Maps)的结构清理一下，虽然说只是单单把涉及CSM算法的代码抽出CMainFrame并不是什么真正的重构，但起码别让一堆代码堆挤在一起吧。一切单纯而懒散地进行着，终于来到了最后一个编译错误（最后一个要改的地方）：

//在CMainFrame中：
//....
CCascadingSM CascadingSM;//CSM对象
//.....
void CMainFrame::RenderObjects()
{.....}

void CMainFrame::RenderGLScene()
{
.....
CascadingSM.GenShadowMap(....);
......
CascadingSM.CastShadowMap(....);
}
//-------------------------类间分割线-------------
//在CCascadingSM中：
void CCascadingSM::GenShadowMap(......)
{
....
（）  //-----本来放RenderObjects()的地方
....
}
void CCascadingSM::CastShadowMap(......)
{
....
（）  //-----本来放RenderObjects()的地方
....
}

熟悉Shadow Map的朋友都知道，GenShadowMap和CastShadowMap就是Shadow Map算法的两步走（两个PASS），分别是光源视觉下对场景生成阴影贴图（深度图），以及把该深度图应用于正常场景中做深度比较以生成阴影。两个函数都需要对场景（也就是RenderObjects()）进行渲染。但是场景RenderObjects不属于CSM算法的一部分，所以我不打算把它交给CCascadingSM类。再者它不大，所以我也不打算让它单独成类，还是把它留在CMainFrame好了。

我看网上一些图形学教程，都喜欢过程式设计，对抽象封装不怎么在意（也许是侧重点不同吧，它们的目的在于呈现图形学API使用，算法之类。但其实我一直觉得单纯图形学作品设计，用过程式思维是最快捷方便的），他们多把东西放一个CPP里搞掂。其实我今天没进行代码整理之前也就这样子了。不过也因此对C++类封装设计不怎么敏感，至于成员函数指针这东西.......

好吧，请原谅我，我以前的处理方法就是把要调用成员函数指针的类，整个static静态化......这样当然不太好，就为了一个成员函数指针把整个类，有辜无辜的都弄变态了。但是当时年少无知的我真的google不出其他解决之道了（现在看来是关键字不对？），乐呵呵地编译成功就继续其他的了。....当然这是个办法，但是这次我忧郁了，因为我面对的是直接的应用类CMainFrame，好吧，我是不敢这样做了。局部静态化呢？不懂，google出来，也不太想看。boost的mem_fun?当时用一次就头疼（VC6还得boost来除BUG呀）。还有一个方法，可以类成员函数里可以保留其他该类的变量啊函数，而且不怕继承那一套的：给个全局的辅助函数吧。

这里有些资料是关于这些方法的：C++指针直接调用类成员函数探讨 ，我正想用它的第3个解决之道，但它里面介绍是同类间调用的，好吧，变通一下就可以了。

//在CMainFrame中：
//....
CCascadingSM CascadingSM;//CSM对象
//.....
void CMainFrame::RenderObjects()
{.....}

//重点：帮拖的全局辅助函数：
void Help_RenderObjects(CMainFrame *mf)
{
    mf->RenderObjects();
}
//////

void CMainFrame::RenderGLScene()
{
.......
CascadingSM.GenShadowMap(this, Help_RenderObjects....);
.......
CascadingSM.CastShadowMap(this, Help_RenderObjects);
}
//-------------------------类间分割线-------------
//在CCascadingSM类中：
class CMainFrame;//前置声明，写在类声明前头
.....
void CCascadingSM::GenShadowMap(CMainFrame *Mf,void (*scene)(CMainFrame *mf)...)
{
....
(*scene)(Mf);  //-----本来放RenderObjects()的地方
....
}
void CCascadingSM::CastShadowMap(CMainFrame *Mf,void (*scene)(CMainFrame *mf))
{
....
(*scene)(Mf);  //-----本来放RenderObjects()的地方
....
}

先看CCascadingSM类，一般的函数指针调用是void (*scene)()这样的吧，这里给它一个参数CMainFrame *mf，因此GenShadowMap函数参数列表要再加个CMainFrame *Mf， 这样调用的时候就可以写(*scene)(Mf);了（该函数指针有多少个参数，就在GenShadowMap函数参数列表里再加多少个对应的变量）。好吧，这里的指针相当于回调函数，回调一个void类型的以CMainFrame对象为参的函数。

我们目的是要让它回调另一个类——CmainFrame的RenderObjects()，这就是成员函数指针调用。然而，直接来是不可以的，因为众所周知，你要获得另一个类里的函数的指针，起码得知道该类生成的某个具体对象的地址。只有具体的东西才有指针而言。那么——我们是要创建一个CmainFrame对象么？不行，一来建这种应用类的对象可是大工程啊，二来就是你建了，那里面的RenderObjects()也不是你要的RenderObjects()了——我要的是在OPENGL窗口里持续运行的CmainFrame类，获得它的办法，就是this指针。

Help_RenderObjects(CMainFrame *mf)是连接一切的小桥梁。它需要的正是一个CMainFrame类型的指针，出来的结果就是这个指针下的成员函数RenderObjects()。明朗起来了，给它this指针，它就给我我所需要的那个RenderObjects()。因此，CCascadingSM类的GenShadowMap函数回调它（参数:this,GenShadowMap）就得到RenderObjects()，注意全局函数或static化的函数是不需要具体对象的支持的。一切完好。

恩，现在我最关心的是：效率如何？也许跟它无关，但是，也不知道调整代码过程中哪里给我出的桩，FPS降低了！！