1 // C++ Return Value Optimization
 2 // 作者：代码疯子
 3 // 博客：http://www.programlife.net/
 4 #include <iostream>
 5 using namespace std;
 6  
 7 class Rational
 8 {
 9 public:
10     Rational(int numerator = 0, int denominator = 1) : 
11       n(numerator), d(denominator)
12       {
13           cout << "Constructor Called" << endl;
14       }
15       ~Rational()
16       {
17           cout << "Destructor Called" << endl;
18       }
19       Rational(const Rational& rhs)
20       {
21           this->d = rhs.d;
22           this->n = rhs.n;
23           cout << "Copy Constructor Called" << endl;
24       }
25       int numerator() const { return n; }
26       int denominator() const { return d; }
27 private:
28     int n, d;
29 };
30  
31 //const Rational operator*(const Rational& lhs,
32 //                         const Rational& rhs)
33 //{
34 //    return Rational(lhs.numerator() * rhs.numerator(),
35 //                    lhs.denominator() * rhs.denominator());
36 //}
37  
38 const Rational operator*(const Rational& lhs,
39                          const Rational& rhs)
40 {
41     cout << "----------- Enter operator* -----------" << endl;
42     Rational tmp(lhs.numerator() * rhs.numerator(),
43         lhs.denominator() * rhs.denominator());
44     cout << "----------- Leave operator* -----------" << endl;
45     return tmp;
46 }
47  
48 int main(int argc, char **argv)
49 {
50     Rational x(1, 5), y(2, 9);
51     Rational z = x * y;
52     cout << "calc result: " << z.numerator() 
53         << "/" << z.denominator() << endl;
54  
55     return 0;
56 }

函数输出截图如下：

可以看到消耗一个构造函数（Constructor）的调用、一个复制构造函数的调用（Copy Constructor）以及一个析构函数（Destructor）的调用的代价。

而如果把operator*换成另一种形式：

1 const Rational operator*(const Rational& lhs,
2                 const Rational& rhs)
3 {
4     return Rational(lhs.numerator() * rhs.numerator(),
5                 lhs.denominator() * rhs.denominator());
6 }



就只会消耗一个构造函数的成本了：

面向对象的系统当中，不可避免的有大量的类间消息传递的需求：一个类需要通知另一个或几个类做些什么。

这种类间消息传递，简单的说，就是调用其他类的方法。

如下：

1void A::OnMessageXX()
2{
3         B::GetInstance()->DoSomething();
4
5}
6
7

在这里，类A需要通知类B做些事情。这种调用在所有的面向对象程序中都是极其常见的。

但是如果类A需要调用类B，就不可避免的产生了耦合性。虽然耦合性终归是不可能完全避免的，但是在一定程度上降低耦合性是完全可能的。

（至于为什么在设计中应该尽可能降低耦合性，不在本文的探讨范围之内）

上面的例子，我们使用了Singleton的模式，从全局作用域中获取了B的实例，并调用了B的相关方法。使用Singleton的一个缺点是，假若我们希望对类A编写测试代码，我们需要做一些额外的解耦合工作。（关于编写测试与解耦合，可以参考Robert C. Martin Series 的Working Effectively with Legacy Code一书，该书的中译版在这 ）

我们也可以通过将B参数化的方法降低A与B间的耦合程度，像下面这样：

现在的写法要比之前的做法耦合性低，通过使用多态的方法，现在传入函数的类B指针可能是另一个实现了B的相应接口的派生类，A并不关心B接口背后的具体实现。

但是等等，你说，现在对类B的耦合性虽然在A中被降低了，但是依旧存在于调用A::OnMessageXX的地方。在那里我们还是需要取得B的实例，然后传递给A。

没错，是这样。

通过参数化类A的方法，我们把类A与类B间的耦合转移了一部分到A的调用者那里。实际上总的耦合并没有消除，只是被分解了。但是程序设计中不可能完全不存在耦合，我们需要做的是”正确”，而不是”完美”。类A的耦合性降低了，使得我们在未来需求变更的时候，类A有更大的可能性不需要被修改，并且对功能的扩展更加友好，这就达成了我们的目标了。

基于上述做法，如果我们在未来扩展是派生出一个B的子类，override相关的方法，那么类A的代码基本是不需要修改的。

不过，问题是，假若A::OnMessageXX中，并不仅仅需要对类B发出消息，还需要对一系列相关的类B1，B2，B3等等发出消息呢？

哦，或许我们可以这样做：

void A::OnMessageXX(const std::list<B*>& lstBInstances)
{
         for (std::list<B*>::const_iterator itr = lstBInstances.begin();
                   itr != lstBInstances.end();
                   ++itr)
         {
                   (*itr)->DoSomething();

         }
}

是的，上面这是一种做法，有一系列B的对象需要被通知到，所以我们可以用一个列表把他们串起来，然后在循环中通知他们去干活。不过这样做的前提是，这一系列B对象都是派生自一个公共基类B，有共通的接口；此外，我们需要在A的OnMessageXX被调用之前构造一个需要接受通知的B对象列表。

当A需要通知B，C，D等一系列没有公共接口的对象的时候，上面的这种做法就无法处理了。

对于B、C、D等需要由A来调用的类来说，它们需要在A通知它们的时候，做一些特定的事情。而又A则是在某些特定的时刻需要通知B、C、D。这样，我们可以把问题看成一个消息响应机制。

B、C、D可以在A的某些事件上注册一些回调函数，当事件发生时，A确保注册该事件的函数被调用到。

如下：

typedef void(callback*)();

class A {

public:

         enum EventIds {

         EVENT_MSG1,

         EVENT_MSG2,

};

void RegisterEvent(int nEventId, callback pfn);

private:

callback m_pfnCallback;

};

现在，B可以调用A::RegisterEvent注册一个事件，并传递一个函数指针给A。

当A中发生了注册的事件时，这个函数指针会被回调到。

不过这种简单的做法适应性很差：

1、  不能支持单个事件的多个callback (可能有很多类都需要注册该事件，并在事件发生时依次被回调)

2、  不能支持多个事件的同时存在

3、  回调函数没有参数’

针对问题1，2，我们可以使用一个事件映射解决问题，做法如下：

typedef int EventId;

typedef void (callback*)();

typedef std::list<callback> CallbackList;

typedef std::map<EventId, CallbackList> CallbackMap;

现在这个数据结构就能够支持多个event同时存在，且每个event都可以支持多个回调函数了。

但是这种用法依旧很不方便，如果类B想要注册A上的一个事件，他需要定义一个 callback类型的函数，并把这个函数的地址传递给A。问题是，往往我们希望类B的回调函数在被调用到的时候，对类B中的数据和状态进行修改，而一个单独的函数，若想获得/修改B中的状态，则必须要与类B紧密耦合。（通过获取全局对象，或者Singleton的方式）

这种紧密耦合引发我们的思考，能否在Callback中同时包含类B的指针与类B的成员函数。

答案是肯定的：泛型回调 就可以做到这一点。关于泛型回调(Generic callback)的信息，在Herb Sutter的Exceptional C++ Style 的35条中有详细介绍。

一下比较简单的泛型回调的定义如下：

class callbackbase {

public:

virtual void operator()() const {};

virtual ~callbackbase() = 0 {};

};

template <class T>

class callback : public callbackbase {

public:

typedef void (T::*Func)();

callback(T& t, Func func) : object(t), f(func) {}     // 绑定到实际对象

void operator() () const { (object->*f)(); }              // 调用回调函数

private:

T* object;

Func f;

};

有了这种泛型回调类，我们就可以将类B的实例与B的成员回调函数绑定在一起注册到容器当中了，而不必再被如何在普通函数中修改B对象状态的问题所困扰了。不过回调函数的参数问题依旧。如果想支持参数，我们不得不对每一种参数类型做一个不同的typedef，像上面定义的这样 typedef void (T::*Func)();（如：typedef void (T::*Func)(int);）

一种解决方案是借助于Any（一种任意类型类）进行参数传递。

但是还有更完善的解决方案，不需要id号，也不需要泛型回调，Ogre采用Listener的方式实现的类间消息传递不仅可以支持单个类B对类A中某个事件的单次/多次注册，也可以支持类B、C、D对同一个事件的注册。而且可以完美的解决参数传递问题。

具体的方案如下：

 1class A {
 2public:
 3         class Listener 
 4        {
 5           public:
 6
 7                   virtual void OnMessageXX(int param1, float param2) = 0;
 8
 9                   virtual void OnMessageYY(int param1, const std::string& param2) = 0;
10
11        };
12
13void registerListener(Listener* obj) 
14{ 
15   m_lstListener.push_back(obj); 
16}
17
18void removeListener(Listener* obj)
19{
20         ListenerList::iterator itr = std::find(m_lstListener.begin(), m_lstListener.end(), obj); 
21
22         if (itr != m_lstListener.end())
23                   m_lstListener.erase(itr);
24}
25
26private:
27         typedef std::list<Listener*> ListenerList;
28
29         ListenerList m_lstListeners;
30};
31
32

有了以上定义，当类A收到某个消息XX之后，只需遍历m_lstListeners列表，调用所有列表成员的OnMessageXX即可。

而所有注册A的消息的类，都必须从A::Listener派生一个类，在它感兴趣的消息处理函数中做出相应处理，而对不感兴趣的消息，只需设为空函数即可。

一个简单的类B的定义如下：

class B {

public:

         friend class BListener;

         class BListener : public A::Listener {

         public:

                   BListener(B* pBInstance) : m_pBInstance(pBInstance) {}

                   virtual void OnMessageXX(int param1, float param2)

{ m_pBInstance->DoSomething(); }

                   virtual void OnMessageYY(int param1, const std::string& param2) {}

         private:

                   B* m_pBInstance;

};

explicit B(A* pAInstance) : m_pAInstance(pAInstance)

{

m_pListener(new BListener(this));

m_pAInstance->registerListener(m_pListener);

}

         ~B() { m_pAInstance->removeListener(m_pListener); delete m_pListener; }

void DoSomething();

private:

         BListener* m_pListener;

}

类B在创建自身实例时，接受一个A的指针（这是合理的，因为类B需要监听类A的消息，理应知道A的存在），并创建一个派生自A::Listener 的监听者对象，并把自身的指针传递给该对象，以使得该监听者改变类B的状态，而后类B将创建好的监听者对象加入到A的监听者列表中。

在B进行析构的时候，需要从A中删除自己注册的监听者。而后将该对象释放。

这种做法的好处：

1、  类B（以及类C等）对类A实现了信息隐藏，类A不再关注任何需要监听它自身消息的其他类，只需关注其自身的状态。从而减低了类A与其他与之关联的类之间的耦合。（类A不必再费尽心机的去获取B的指针，不管是通过全局变量，还是Singleton，还是参数，还是类成员变量，都不再需要了，A只关心在 Listener中定义好的一组接口即可）而且，如果有必要类B可以对同一个消息注册多次，且可以对同一消息有不同的反应（通过定义不同的 BListener实现达到这一目的），只需在B不再需要监听相关消息时将所注册过的对象注销掉即可。

2、  由于1中所述，类A的实现无需关心类B的实现，因此类A的逻辑中不需要包含任何类B的方法调用，从而，类A的cpp文件中，无需包含类B的头文件，（可能还包括类C，D等等，此处类B指代需要根据类A状态而做出动作的类）从而降低编译时间，这是解耦合所带来的附加好处。

3、  同样是解耦合带来的好处：因为无需关注类B等等其他类的实现，类A的代码逻辑变得更加清晰，并且减少未来逻辑需求变更的改动所需要付出的代价（逻辑变更可能需要更改接口，需要增加状态判断，无论是调试时间还是编译时间都是不可忽视的代价）。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/zougangx/archive/2009/07/30/4395775.aspx

 1#include <stdlib.h>
 2#include <stdio.h>
 3 
 4void fn1( void ), fn2( void ), fn3( void ), fn4( void );
 5 
 6void main( void )
 7{
 8  atexit( fn1 );
 9  atexit( fn2 );
10  atexit( fn3 );
11  atexit( fn4 );
12  printf( "This is executed first.\n" );
13}
14 
15void fn1()
16{
17  printf( "next.\n" );
18}
19 
20void fn2()
21{
22  printf( "executed " );
23}
24 
25void fn3()
26{
27  printf( "is " );
28}
29 
30void fn4()
31{
32  printf( "This " );
33}
34

编译、运行程序后，程序的输出为：
This is executed first.
This is executed next.
注册函数的顺序为：fn1、fn2、fn3、fn4，但是调用顺序为fn4、fn3、fn2、fn1。

2、理解了atexit函数之后，我们就可以来看看局部静态对象了。

在调试状态下，汇编代码如下(请观察蓝色标记出来的代码)：
AAA* createAAA()
{
     …
     static AAA a ;
…
[1] 00401056 call        AAA::AAA (4010A0h)
[2] 0040105B push      offset `createAAA'::`2'::a::`dynamic atexit destructor' (442410h)
[3] 00401060 call        atexit (409A50h)
00401065 add            esp,4
00401068 mov           dword ptr [ebp-4],0FFFFFFFFh
     return &a ;
0040106F mov           eax,offset a (452620h)
}
…
00401091 ret  
注：[1]、[2]、[3]为方便说明加入的字符，实际代码中并不存在。
[1]语句很明显的调用AAA的构造函数。
[2]语句将442410h压入栈中。
[3]语句调用atexit函数，根据我们的了解，atexit的参数应该是函数指针。那么我们来分析一下442410h处的代码，从注释来看，我们看到了destructor。代码如下：
`createAAA'::`2'::a::`dynamic atexit destructor':
…
[1] 0044242E mov         ecx,offset a (452620h)
[2] 00442433 call        AAA::~AAA (403A90h)
…
0044244B ret           
[1]语句将a的地址放在ecx寄存器中，这是this调用规范的风格。
[2]语句调用AAA的析构函数。

程序结束时，将调用atexit函数注册的442410h处的函数，进而调用了AAA的析构函数。从而保证了析构函数的调用。

 
3、   了解了局部静态对象之后，我们来看看全局对象。
我们知道全局对象必须在main函数前已经被构造。为了弄清楚全局对象何时被构造，我在全局对象的实例化处设置了断点，调用堆栈如下：
static.exe!aaaa::`dynamic initializer'() Line 22 C++
static.exe!_initterm(void (void)* * pfbegin=0x00451038, void (void)* * pfend=0x00451064) Line 707 C
static.exe!_cinit(int initFloatingPrecision=1) Line 208 + 0xf bytes C
static.exe!mainCRTStartup() Line 266 + 0x7 bytes C

作为对比，我在AAA的析构函数出设置了断点，调用堆栈如下：
     static.exe!AAA::~AAA() Line 19  C++
     static.exe!aaaa::`dynamic atexit destructor'() + 0x28 bytes  C++
     static.exe!doexit(int code=0, int quick=0, int retcaller=0) Line 451  C
     static.exe!exit(int code=0) Line 311 + 0xd bytes  C
     static.exe!mainCRTStartup() Line 289  C

由此我们可以看出程序的实际入口点位mainCRTStartup而不是main函数（相对于ANSI的控制台程序而言）。
我们来分析一下_cinit函数：
注释中有一句[3. General C initializer routines]，看来该函数的功能之一是完成C的初始化例程。
函数的核心代码如下：
/*
         * do initializations
         */
        initret = _initterm_e( __xi_a, __xi_z );
/*
         * do C++ initializations
         */
        _initterm( __xc_a, __xc_z );
看来该函数主要进行C、C++的初始化。我们进一步分析函数_initterm_e和_initterm，两个函数的功能进本相同，都是遍历函数指针（由参数指定函数指针的开始位置[__xi_a、__xi_z]、结束位置[__xc_a、__xc_z]），如果函数指针不为null，那么调用该函数。
那么__xi_a、__xi_z和__xc_a、__xc_z到底代表了什么呢？在cinitexe.c文件中有如下代码：
#pragma data_seg(".CRT$XIA")
_CRTALLOC(".CRT$XIA") _PVFV __xi_a[] = { NULL };
 
#pragma data_seg(".CRT$XIZ")
_CRTALLOC(".CRT$XIZ") _PVFV __xi_z[] = { NULL };/* C initializers */
 
#pragma data_seg(".CRT$XCA")
_CRTALLOC(".CRT$XCA") _PVFV __xc_a[] = { NULL };
 
#pragma data_seg(".CRT$XCZ")
_CRTALLOC(".CRT$XCZ") _PVFV __xc_z[] = { NULL };/* C++ initializers */
#pragma comment(linker, "/merge:.CRT=.data")
可以看出这四个变量分别在数据段.CRT$XIA、.CRT$XIZ、.CRT$XCA、.CRT$XCZ中。当连接器布局代码时，它按根据的名称，按照字母排序的规则，排列所有段。这样在段.CRT$XIA中的变量出现在段.CRT$XIZ所有变量之前，从而形成链表。对于.CRT$XCA、.CRT$XCZ数据段同理。最后这四个数据段被合并到.data数据段中。
再看看这些变量的类型，typedef void (__cdecl *_PVFV)(void); 所以这些变量组成了2个初始化函数指针链表。
调试过程中，看到__xc_a、__xc_z链表中，指向的初始化函数很多是构造函数，如：
static std::_Init_locks initlocks;
static filebuf fout(_cpp_stdout);
extern _CRTDATA2 ostream cout(&fout);
cout对象也在此时被构造。
对于析构函数的调用也是采用相同的方式，只是此时每一种初始化，都有一种终止函数与之对应。

4、 总结
l         编译、连接程序时，编译器将所有全局对象的初始化函数放入.CRT$Xx中，连接器将所有的.CRT$XCx段合并成为.rdata数据段。在.CRT$XCA 到 .CRT$XCZ的所有段的数据组成初始化函数指针列表。
l   函数执行时，_initterm( __xc_a, __xc_z )函数调用所有的初始化函数。构造全局对象。构造对象完毕，调用atexit函数来保证析构函数的调用。Modern C++ Design就是通过控制调用atexit函数来决定对象的析构顺序的。
l   对于静态对象使用atexit来保证析构函数的调用。
l    程序结束时，调用exit来析构全局对象或静态对象。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/coffeemay/archive/2006/11/19/1395250.aspx

转载： 

Debug版本包括调试信息，所以要比Release版本大很多（可能大数百K至数M）。至于是否需要DLL支持，主要看你采用的编译选项。如果是基于ATL的，则Debug和Release版本对DLL的要求差不多。如果采用的编译选项为使用MFC动态库，则需要MFC42D.DLL等库支持，而Release版本需要MFC42.DLL支持。Release   Build不对源代码进行调试，不考虑MFC的诊断宏，使用的是MFC   Release库，编译十对应用程序的速度进行优化，而Debug   Build则正好相反，它允许对源代码进行调试，可以定义和使用MFC的诊断宏，采用MFC   Debug库，对速度没有优化。   

一、Debug   和   Release   编译方式的本质区别 

Debug   通常称为调试版本，它包含调试信息，并且不作任何优化，便于程序员调试程序。Release   称为发布版本，它往往是进行了各种优化，使得程序在代码大小和运行速度上都是最优的，以便用户很好地使用。 
Debug   和   Release   的真正秘密，在于一组编译选项。下面列出了分别针对二者的选项（当然除此之外还有其他一些，如/Fd   /Fo，但区别并不重要，通常他们也不会引起   Release   版错误，在此不讨论） 

Debug   版本： 
/MDd   /MLd   或   /MTd   使用   Debug   runtime   library(调试版本的运行时刻函数库) 
/Od   关闭优化开关 
/D   "_DEBUG"   相当于   #define   _DEBUG,打开编译调试代码开关(主要针对 
assert函数) 
/ZI   创建   Edit   and   continue(编辑继续)数据库，这样在调试过 
程中如果修改了源代码不需重新编译 
/GZ   可以帮助捕获内存错误 
/Gm   打开最小化重链接开关，减少链接时间 

Release   版本：   
/MD   /ML   或   /MT   使用发布版本的运行时刻函数库 
/O1   或   /O2   优化开关，使程序最小或最快 
/D   "NDEBUG"   关闭条件编译调试代码开关(即不编译assert函数) 
/GF   合并重复的字符串，并将字符串常量放到只读内存，防止 
被修改 

实际上，Debug   和   Release   并没有本质的界限，他们只是一组编译选项的集合，编译器只是按照预定的选项行动。事实上，我们甚至可以修改这些选项，从而得到优化过的调试版本或是带跟踪语句的发布版本。 

二、哪些情况下   Release   版会出错 

有了上面的介绍，我们再来逐个对照这些选项看看   Release   版错误是怎样产生的 

1.   Runtime   Library：链接哪种运行时刻函数库通常只对程序的性能产生影响。调试版本的   Runtime   Library   包含了调试信息，并采用了一些保护机制以帮助发现错误，因此性能不如发布版本。编译器提供的   Runtime   Library   通常很稳定，不会造成   Release   版错误；倒是由于   Debug   的   Runtime   Library   加强了对错误的检测，如堆内存分配，有时会出现   Debug   有错但   Release   正常的现象。应当指出的是，如果   Debug   有错，即使   Release   正常，程序肯定是有   Bug   的，只不过可能是   Release   版的某次运行没有表现出来而已。 

2.   优化：这是造成错误的主要原因，因为关闭优化时源程序基本上是直接翻译的，而打开优化后编译器会作出一系列假设。这类错误主要有以下几种： 

(1)   帧指针(Frame   Pointer)省略（简称   FPO   ）：在函数调用过程中，所有调用信息（返回地址、参数）以及自动变量都是放在栈中的。若函数的声明与实现不同（参数、返回值、调用方式），就会产生错误————但   Debug   方式下，栈的访问通过   EBP   寄存器保存的地址实现，如果没有发生数组越界之类的错误（或是越界“不多”），函数通常能正常执行；Release   方式下，优化会省略   EBP   栈基址指针，这样通过一个全局指针访问栈就会造成返回地址错误是程序崩溃。C++   的强类型特性能检查出大多数这样的错误，但如果用了强制类型转换，就不行了。你可以在   Release   版本中强制加入   /Oy-   编译选项来关掉帧指针省略，以确定是否此类错误。此类错误通常有： 

●   MFC   消息响应函数书写错误。正确的应为 
afx_msg   LRESULT   OnMessageOwn(WPARAM   wparam,   LPARAM   lparam); 
ON_MESSAGE   宏包含强制类型转换。防止这种错误的方法之一是重定义   ON_MESSAGE   宏，把下列代码加到   stdafx.h   中（在#include   "afxwin.h"之后）,函数原形错误时编译会报错 
#undef   ON_MESSAGE 
#define   ON_MESSAGE(message,   memberFxn)   \ 
{   message,   0,   0,   0,   AfxSig_lwl,   \ 
(AFX_PMSG)(AFX_PMSGW)(static_cast<   LRESULT   (AFX_MSG_CALL   \ 
CWnd::*)(WPARAM,   LPARAM)   >   (&memberFxn)   }, 

(2)   volatile   型变量：volatile   告诉编译器该变量可能被程序之外的未知方式修改（如系统、其他进程和线程）。优化程序为了使程序性能提高，常把一些变量放在寄存器中（类似于   register   关键字），而其他进程只能对该变量所在的内存进行修改，而寄存器中的值没变。如果你的程序是多线程的，或者你发现某个变量的值与预期的不符而你确信已正确的设置了，则很可能遇到这样的问题。这种错误有时会表现为程序在最快优化出错而最小优化正常。把你认为可疑的变量加上   volatile   试试。 

(3)   变量优化：优化程序会根据变量的使用情况优化变量。例如，函数中有一个未被使用的变量，在   Debug   版中它有可能掩盖一个数组越界，而在   Release   版中，这个变量很可能被优化调，此时数组越界会破坏栈中有用的数据。当然，实际的情况会比这复杂得多。与此有关的错误有： 
●   非法访问，包括数组越界、指针错误等。例如 
void   fn(void) 
{ 
int   i; 
i   =   1; 
int   a[4]; 
{ 
int   j; 
j   =   1; 
} 
a[-1]   =   1;//当然错误不会这么明显，例如下标是变量 
a[4]   =   1; 
} 
j   虽然在数组越界时已出了作用域，但其空间并未收回，因而   i   和   j   就会掩盖越界。而   Release   版由于   i、j   并未其很大作用可能会被优化掉，从而使栈被破坏。 

3.   _DEBUG   与   NDEBUG   ：当定义了   _DEBUG   时，assert()   函数会被编译，而   NDEBUG   时不被编译。除此之外，VC++中还有一系列断言宏。这包括： 

ANSI   C   断言   void   assert(int   expression   ); 
C   Runtime   Lib   断言   _ASSERT(   booleanExpression   ); 
_ASSERTE(   booleanExpression   ); 
MFC   断言   ASSERT(   booleanExpression   ); 
VERIFY(   booleanExpression   ); 
ASSERT_VALID(   pObject   ); 
ASSERT_KINDOF(   classname,   pobject   ); 
ATL   断言   ATLASSERT(   booleanExpression   ); 
此外，TRACE()   宏的编译也受   _DEBUG   控制。 

所有这些断言都只在   Debug版中才被编译，而在   Release   版中被忽略。唯一的例外是   VERIFY()   。事实上，这些宏都是调用了   assert()   函数，只不过附加了一些与库有关的调试代码。如果你在这些宏中加入了任何程序代码，而不只是布尔表达式（例如赋值、能改变变量值的函数调用   等），那么   Release   版都不会执行这些操作，从而造成错误。初学者很容易犯这类错误，查找的方法也很简单，因为这些宏都已在上面列出，只要利用   VC++   的   Find   in   Files   功能在工程所有文件中找到用这些宏的地方再一一检查即可。另外，有些高手可能还会加入   #ifdef   _DEBUG   之类的条件编译，也要注意一下。 
顺便值得一提的是   VERIFY()   宏，这个宏允许你将程序代码放在布尔表达式里。这个宏通常用来检查   Windows   API   的返回值。有些人可能为这个原因而滥用   VERIFY()   ，事实上这是危险的，因为   VERIFY()   违反了断言的思想，不能使程序代码和调试代码完全分离，最终可能会带来很多麻烦。因此，专家们建议尽量少用这个宏。 

4.   /GZ   选项：这个选项会做以下这些事 

(1)   初始化内存和变量。包括用   0xCC   初始化所有自动变量，0xCD   (   Cleared   Data   )   初始化堆中分配的内存（即动态分配的内存，例如   new   ），0xDD   (   Dead   Data   )   填充已被释放的堆内存（例如   delete   ），0xFD(   deFencde   Data   )   初始化受保护的内存（debug   版在动态分配内存的前后加入保护内存以防止越界访问），其中括号中的词是微软建议的助记词。这样做的好处是这些值都很大，作为指针是不可能的（而且   32   位系统中指针很少是奇数值，在有些系统中奇数的指针会产生运行时错误），作为数值也很少遇到，而且这些值也很容易辨认，因此这很有利于在   Debug   版中发现   Release   版才会遇到的错误。要特别注意的是，很多人认为编译器会用   0   来初始化变量，这是错误的（而且这样很不利于查找错误）。 
(2)   通过函数指针调用函数时，会通过检查栈指针验证函数调用的匹配性。（防止原形不匹配） 
(3)   函数返回前检查栈指针，确认未被修改。（防止越界访问和原形不匹配，与第二项合在一起可大致模拟帧指针省略   FPO   ） 

通常   /GZ   选项会造成   Debug   版出错而   Release   版正常的现象，因为   Release   版中未初始化的变量是随机的，这有可能使指针指向一个有效地址而掩盖了非法访问。 

除此之外，/Gm   /GF   等选项造成错误的情况比较少，而且他们的效果显而易见，比较容易发现。 
-------------------------------------------------------------- 
Release是发行版本,比Debug版本有一些优化，文件比Debug文件小 
Debug是调试版本，包括的程序信息更多 
Release方法： 
build->batch   build->build就OK. 

----------------------------------------------------- 

一、"Debug是调试版本，包括的程序信息更多" 

补充：只有DEBUG版的程序才能设置断点、单步执行、使用TRACE/ASSERT等调试输出语句。REALEASE不包含任何调试信息，所以体积小、运行速度快。 

二、一般发布release的方法除了hzh_shat(水)   所说的之外，还可以project->Set   Active   Config，选中release版本。此后，按F5或F7编译所得的结果就是release版本。

Trackback: http://tb.donews.net/TrackBack.aspx?PostId=131016

----------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
VC下关于debug和release的不同的讨论
在使用VC开发软件的过程中，正当要享受那种兴奋的时候突然发现：release与debug运行结果不一致，甚至出错，而release又不方便调试，真的是当头一棒啊，可是疼归疼，问题总要解决，下面将讲述一下我的几点经验，看看是不是其中之一：

1. 变量。
大家都知道，debug跟release在初始化变量时所做的操作是不同的，debug是将每个字节位都赋成0xcc(注1)，而release的赋值近似于随机(我想是直接从内存中分配的，没有初始化过)。这样就明确了，如果你的程序中的某个变量没被初始化就被引用，就很有可能出现异常：用作控制变量将导致流程导向不一致；用作数组下标将会使程序崩溃；更加可能是造成其他变量的不准确而引起其他的错误。所以在声明变量后马上对其初始化一个默认的值是最简单有效的办法，否则项目大了你找都没地方找。代码存在错误在debug方式下可能会忽略而不被察觉到，如debug方式下数组越界也大多不会出错，在release中就暴露出来了，这个找起来就比较难了:( 还是自己多加注意吧

2. 自定义消息的消息参数。
MFC为我们提供了很好的消息机制，更增加了自定义消息，好处我就不用多说了。这也存在debug跟release的问题吗？答案是肯定的。在自定义消息的函数体声明时，时常会看到这样的写法：afx_msg LRESULT OnMessageOwn(); Debug情况下一般不会有任何问题，而当你在Release下且多线程或进程间使用了消息传递时就会导致无效句柄之类的错误。导致这个错误直接原因是消息体的参数没有添加，即应该写成：afx_msg LRESULT OnMessageOwn(WPARAM wparam, LPARAM lparam); (注2)

3. release模式下不出错，但debug模式下报错。
这种情况下大多也是因为代码书写不正确引起的，查看MFC的源码，可以发现好多ASSERT的语句(断言)，这个宏只是在debug模式下才有效，那么就清楚了，release版不报错是忽略了错误而不是没有错误，这可能存在很大的隐患，因为是Debug模式下，比较方便调试，好好的检查自己的代码，再此就不多说了。

4. ASSERT, VERIFY, TRACE……….调试宏
这种情况很容易解释。举个例子：请在VC下输入ASSERT然后选中按F12跳到宏定义的地方，这里你就能够发现Debug中ASSERT要执行AfxAssertFailedLine，而Release下的宏定义却为”#define ASSERT(f) ((void)0)”。所以注意在这些调试宏的语句不要用程序相关变量如i++写操作的语句。VERIFY是个例外，”#define VERIFY(f) ((void)(f))”，即执行，这里的作用就不多追究了，有兴趣可自己研究:)。

总结：
Debug与Release不同的问题在刚开始编写代码时会经常发生，99%是因为你的代码书写错误而导致的，所以不要动不动就说系统问题或编译器问题，努力找找自己的原因才是根本。我从前就常常遇到这情况，经历过一次次的教训后我就开始注意了，现在我所写过的代码我已经好久没遇到这种问题了。下面是几个避免的方面，即使没有这种问题也应注意一下：

1. 注意变量的初始化，尤其是指针变量，数组变量的初始化(很大的情况下另作考虑了)。
2. 自定义消息及其他声明的标准写法
3. 使用调试宏时使用后最好注释掉
4. 尽量使用try - catch(…)
5. 尽量使用模块，不但表达清楚而且方便调试。
注1：
afc(afc) 网友提供：
debug版初始化成0xcc是因为0xcc在x86下是一条int 3单步中断指令，这样程序如果跑飞了遇到0xcc就会停下来，这和单片机编程时一般将没用的代码空间填入jmp 0000语句是一样地
注2：
不知大家有没有遇到过这种情况，具体原因我也不太清楚，是不是调用时按着默认的参数多分配了WPARAM+LPARAM的空间而破坏了应用程序的内存空间?还请高手来补充。
NightWolf 网友提供：我遇见过，好像是在函数调用的时候参数入栈的问题。因为MFC的消息使用宏写的，所以如果定义了OnMessage()的函数，编译能够通过，但是调用一次后，堆栈指针发生了偏移。然后就。。。
------------------------------------------------------------
_________________________________________________________
---------------------------------------------------------
DEBUG和RELEASE 版本差异及调试相关问题：

I.          内存分配问题

1.           变量未初始化。下面的程序在debug中运行的很好。

       thing * search(thing * something)
         BOOL found;
         for(int i = 0; i < whatever.GetSize(); i++)
           {
           if(whatever[i]->field == something->field)
              { /* found it */
               found = TRUE;
               break;
              } /* found it */
            }
     if(found)
              return whatever[i];
     else
              return NULL;
而在release中却不行，因为debug中会自动给变量初始化found=FALSE,而在release版中则不会。所以尽可能的给变量、类或结构初始化。

2.             数据溢出的问题 

         如：char buffer[10];
              int counter;

        lstrcpy(buffer, "abcdefghik");

在debug版中buffer的NULL覆盖了counter的高位，但是除非counter>16M,什么问题也没有。但是在release版中，counter可能被放在寄存器中，这样NULL就覆盖了buffer下面的空间，可能就是函数的返回地址，这将导致ACCESS ERROR。

3.          DEBUG版和RELEASE版的内存分配方式是不同的 。如果你在DEBUG版中申请    ele 为 6*sizeof(DWORD)=24bytes,实际上分配给你的是32bytes（debug版以32bytes为单位分配）， 而在release版，分配给你的就是24bytes（release版以8bytes为单位），所以在debug版中如果你写ele[6],可能不会有什么问题，而在release版中，就有ACCESS VIOLATE。

II.       ASSERT和VERIFY

1.          ASSERT在Release版本中是不会被编译的。

ASSERT宏是这样定义的

         #ifdef _DEBUG
         #define ASSERT(x) if( (x) == 0) report_assert_failure()
         #else
         #define ASSERT(x)
         #endif
         实际上复杂一些，但无关紧要。假如你在这些语句中加了程序中必须要有的代码
比如

ASSERT(pNewObj = new CMyClass);

pNewObj->MyFunction();

这种时候Release版本中的pNewObj不会分配到空间

所以执行到下一个语句的时候程序会报该程序执行了非法操作的错误。这时可以用VERIFY ：

         #ifdef _DEBUG
         #define VERIFY(x) if( (x) == 0) report_assert_failure()
     #else
         #define VERIFY(x) (x)
         #endif
这样的话，代码在release版中就可以执行了。

III.    参数问题：

自定义消息的处理函数，必须定义如下：

afx_msg LRESULT OnMyMessage(WPARAM, LPARAM);

返回值必须是HRESULT型，否则Debug会过，而Release出错

IV.   内存分配

保证数据创建和清除的统一性：如果一个DLL提供一个能够创建数据的函数，那么这个DLL同时应该提供一个函数销毁这些数据。数据的创建和清除应该在同一个层次上。

V.      DLL的灾难

人们将不同版本DLL混合造成的不一致性形象的称为 “动态连接库的地狱“(DLL Hell) ，甚至微软自己也这么说(http://msdn.microsoft.com/library/techart/dlldanger1.htm)。

        如果你的程序使用你自己的DLL时请注意：

1.        不能将debug和release版的DLL混合在一起使用。debug都是debug版，release版都是release版。

解决办法是将debug和release的程序分别放在主程序的debug和release目录下

2.          千万不要以为静态连接库会解决问题，那只会使情况更糟糕。

VI.   RELEASE板中的调试 ：

1.          将ASSERT() 改为 VERIFY() 。找出定义在"#ifdef _DEBUG"中的代码，如果在RELEASE版本中需要这些代码请将他们移到定义外。查找TRACE(...)中代码，因为这些代码在RELEASE中也不被编译。 请认真检查那些在RELEASE中需要的代码是否并没有被便宜。

2.          变量的初始化所带来的不同，在不同的系统，或是在DEBUG/RELEASE版本间都存在这样的差异，所以请对变量进行初始化。

3.          是否在编译时已经有了警告?请将警告级别设置为3或4,然后保证在编译时没有警告出现.

VII.    将Project Settings" 中 "C++/C " 项目下优化选项改为Disbale（Debug）。编译器的优化可能导致许多意想不到的错误，请参考http://www.pgh.net/~newcomer/debug_release.htm

1.          此外对RELEASE版本的软件也可以进行调试，请做如下改动：

在"Project Settings" 中 "C++/C " 项目下设置 "category" 为 "General" 并且将"Debug Info"设置为 "Program Database"。

在"Link"项目下选中"Generate Debug Info"检查框。

"Rebuild All"

如此做法会产生的一些限制：

无法获得在MFC DLL中的变量的值。

必须对该软件所使用的所有DLL工程都进行改动。

另：

MS BUG：MS的一份技术文档中表明，在VC5中对于DLL的"Maximize Speed"优化选项并未被完全支持，因此这将会引起内存错误并导致程序崩溃。

2.         www.sysinternals.com有一个程序DebugView，用来捕捉OutputDebugString的输出，运行起来后（估计是自设为system debugger）就可以观看所有程序的OutputDebugString的输出。此后，你可以脱离VC来运行你的程序并观看调试信息。

3.          有一个叫Gimpel Lint的静态代码检查工具，据说比较好用。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/Jiao2_vc/archive/2009/03/07/3967364.aspx

个人感觉对于类的成员函数指针这块讲解的比较深入详细

推荐阅读

/////////////////////////////////////////////////

先看这样一段代码

class test
{
   public:
      test(int i){ m_i=i;}
      test(){}

      void hello()
      {
           printf("hello\n");
      }
   private:
       int m_i;
};

int main()
{
     test *p=new test();
     p->hello();
     p=NULL;
     p->hello();
}

结果是:

hello

hello

为何

p=NULL;
     p->hello();   这样之后，NULL->hello()也依然有效呢？

我们第一反应一定是觉得类的实例的成员函数，不同于成员变量，成员函数全部都存在同一个地方，所以的类的实例来调用的时候，一定是调用相同的函数指针。（想想也是有道理的，成员函数都是一样的功能，根本不需要实例化多个）

于是我们把代码改成这样

class test
{
    public:
        test(int i){ m_i=i;}
        test(){}

        void hello()
        {
            printf("hello\n");
        }

    private:
        int m_i;
};

typedef void (test::*HELLO_FUNC)();

int main()
{
     test *p=new test();
      test q;
      p->hello();
      HELLO_FUNC phello_fun=&test::hello;
      printf("%p\n",phello_fun);
      p=NULL;
      phello_fun=&test::hello;
      printf("%p\n",phello_fun);
      phello_fun=p->hello;
      printf("%p\n",phello_fun);
      phello_fun=q.hello;
      printf("%p\n",phello_fun);
      p->hello();
}

结果是：

hello
00401005
00401005
00401005
00401005
hello
Press any key to continue

也就是说不管是&test::hello,还是p->hello，或者q.hello,甚至于NULL->hello.

调用的地址都是0x00401005,也基本印证了我们的猜想。

事情到这里算是完了么？没有。

有人问道这样一段代码：

SSVector& SSVector::assign2product4setup(const SVSet& A, const SSVector& x)
{
    int    ret_val= 

pthread_create(&pt,NULL,(void(*)(void*))SSVector::prefun,x);
}

void* SSVector::prefun (void* arg){
         const SSVector &tx =*((SSVector*) arg);
}
行报错：invalid conversion from 'void (*)(void*)' to 'void* (*)(void*)'

pthread_create我就不解释了，第3个参数是线程函数的指针，为何这里报错呢？

说明普通的类成员函数的指针（如果它有函数指针的话），不同于一般的函数指针。

看看下面这篇文章关于这个问题的分析：

前言：在CSDN论坛经常会看到一些关于类成员函数指针的问题，起初我并不在意，以为成员函数指针和普通的函数指针是一样的，没有什么太多需要讨论的。当我找来相关书籍查阅了一番以后，突然意识到我以前对成员函数指针的理解太过于幼稚和肤浅了，它即不像我以前认为的那样简单,它也不像我以前认为的那样"默默无闻"。强烈的求知欲促使我对成员函数进行进一步的学习并有了这篇文章。

一。理论篇
在进行深入学习和分析之前，还是先看看书中是怎么介绍成员函数的。总结一下类成员函数指针的内容，应该包含以下几个知识点：
1。成员函数指针并不是普通的函数指针。
2。编译器提供了几个新的操作符来支持成员函数指针操作：

1) 操作符"::*"用来声明一个类成员函数指针，例如：
    typedef void (Base::*PVVBASEMEMFUNC)(void);        //Base is a class
2) 操作符"->*"用来通过对象指针调用类成员函数指针，例如：
    //pBase is a Base pointer and well initialized
    //pVIBaseMemFunc is a member function pointer and well initialized
    (pBase->*pVIBaseMemFunc)();
3) 操作符".*"用来通过对象调用类成员函数指针，例如：
    //baseObj is a Base object
    //pVIBaseMemFunc is a member function pointer and well initialized
    (baseObj.*pVIBaseMemFunc)();

3。成员函数指针是强类型的。

    typedef void (Base::*PVVBASEMEMFUNC)(void);
    typedef void (Derived::*PVVDERIVEMEMFUNC)(void);
PVVBASEMEMFUNC和PVVDERIVEMEMFUNC是两个不同类型的成员函数指针类型。

4。由于成员函数指针并不是真真意义上的指针，所以成员函数指针的转化就受限制。具体的转化细节依赖于不同的编译器，甚至是同一个编译器的不同版本。不过，处于同一个继承链中的不同类之间override的不同函数和虚函数还是可以转化的。

    void* pVoid = reinterpret_cast<void*>(pVIBaseMemFunc);            //error
    int*  pInt  = reinterpret_cast<int*>(pVIBaseMemFunc);             //error
  pVIDeriveMemFunc = static_cast<PVIDERIVEMEMFUNC>(pVIBaseMemFunc);   //OK

二。实践篇
有了上面的理论知识，我们对类成员函数指针有了大概的了解，但是我们对成员函数指针还存在太多的疑惑。既然说成员函数指针不是指针，那它到底是什么东东? 编译器为什么要限制成员函数指针转化？老办法，我们还是分析汇编代码揭示其中的秘密。首先，我写了这样两个具有继承关系的类：
接着，我又定义了一些成员函数指针类型：
最后，在main函数写了一些测试代码：
成功编译后生成汇编代码。老规矩，在分析汇编代码的过程中还是只分析对解决问题有意义的汇编代码，其他的就暂时忽略。
1。成员函数指针不是指针。从代码看出，在main函数的调用栈(calling stack)中首先依次压入四个成员函数指针，如果它们是普通指针的话，它们之间的偏移量应该是4个字节,可是实际的情况却是这样的：

 ”The implementation of the pointer to member function must store within itself information as to whether the member function to which it refers is virtual or nonvirtual, information about where to find the appropriate virtual function table pointer (see The Compiler Puts Stuff in Classes [11, 37]), an offset to be added to or subtracted from the function's this pointer (see Meaning of Pointer Comparison [28, 97]), and possibly other information. A pointer to member function is commonly implemented as a small structure that contains this information, although many other implementations are also in use. Dereferencing and calling a pointer to member function usually involves examining the stored information and conditionally executing the appropriate virtual or nonvirtual function calling sequence.“

2。成员函数指针的转化。本文所采用的代码是想比较普通成员函数指针和虚函数指针在转化的过程中存在那些差异：
对于符号”??_9@$B3AE“，我又找到了这样的汇编代码： 由此可以看出，对于虚函数，即使是用过成员函数指针间接调用，仍然具有和直接调用一样的特性。

    ; PVIBASEMEMFUNC pVIBaseMemFunc = &Base::setValue;
    mov    DWORD PTR _pVIBaseMemFunc$[ebp], OFFSET FLAT:?setValue@Base@@QAEXH@Z ;
    取出Base::setValue函数的地址，存放于变量pVIBaseMemFunc所占内存的前4个字节(DWORD)中。

; PVVBASEMEMFUNC      pVVBaseMemFunc   = &Base::foobar;
mov    DWORD PTR _pVVBaseMemFunc$[ebp], OFFSET FLAT:??_9@$B3AE ; `vcall'
取出符号”??_9@$B3AE“的值，存放于变量pVVBaseMemFunc所占内存的前4个字节(DWORD)中。

    _TEXT    SEGMENT
    ??_9@$B3AE PROC NEAR                    ; `vcall', COMDAT
    mov    eax, DWORD PTR [ecx]
    jmp    DWORD PTR [eax+4]
    ??_9@$B3AE ENDP                        ; `vcall'
    _TEXT    ENDS
符号”??_9@$B3AE“代表的应该是一个存根函数，这个函数首先根据this指针获得虚函数表的指针，然后将指令再跳转到相应的虚函数的地址。

    ; PVIDERIVEMEMFUNC pVIDeriveMemFunc = static_cast<PVIDERIVEMEMFUNC>(pVIBaseMemFunc);
    mov    eax, DWORD PTR _pVIBaseMemFunc$[ebp]
    mov    DWORD PTR _pVIDeriveMemFunc$[ebp], eax
直接将变量pVIBaseMemFunc所占内存的前4个字节(DWORD)的值付给了变量_pVIDeriveMemFunc所占内存的前4个字节中。

    ; PVVDERIVEMEMFUNC    pVVDeriveMemFunc = static_cast<PVVDERIVEMEMFUNC>(pVVBaseMemFunc);
    mov    eax, DWORD PTR _pVVBaseMemFunc$[ebp]
    mov    DWORD PTR _pVVDeriveMemFunc$[ebp], eax
直接将变量pVVBaseMemFunc所占内存的前4个字节(DWORD)的值付给了变量pVVDeriveMemFunc所占内存的前4个字节中。

由此可以看出，基类的成员函数指针转化到相应的派生类的成员函数指针，值保持不变。当然这里的例子继承关系相对来说比较简单，如果存在多继承和虚继承的情况下，结果可能会复杂的多。

3。函数调用
下面的函数调用都大同小异，这里是列出其中的一个： 这里的汇编代码并没有给我们太多新鲜的内容：将对象的首地址(this指针)存放于寄存器ECX中，接着就将指令转到变量_pVIBaseMemFunc所占内存的前4个字节所表示的地址。

到了这里，我们应该对成员函数指针有了进一步的了解。

    ; (baseObj.*pVIBaseMemFunc)(10);
    mov    esi, esp
    push    10                    ; 0000000aH
    lea    ecx, DWORD PTR _baseObj$[ebp]
    call    DWORD PTR _pVIBaseMemFunc$[ebp]
    cmp    esi, esp
    call    __RTC_CheckEsp  

由此可以看出，他们之间的偏移量是12个字节。这12个字节中应该可以包含三个指针，其中的一个指针应该指向函数的地址，那另外两个指针又指向那里呢？在《C++ Common Knowledge: Essential Intermediate Programming》(中文译名：

C++必知必会)这本书的第16章对这部分的内容做了说明，这个12个字节的偏移量正好印证了书中的内容：

class Base {
public:
    //ordinary member function
    void setValue(int iValue);

    //virtual member function
    virtual void dumpMe();
    virtual void foobar();

protected:
    int m_iValue;
};

class Derived:public Base{
public:
    //ordinary member function
    void setValue(int iValue);

    //virtual member function
    virtual void dumpMe();
    virtual void foobar();
private:
    double m_fValue;
};

    typedef void (Base::*PVVBASEMEMFUNC)(void);
    typedef void (Derived::*PVVDERIVEMEMFUNC)(void);
    typedef void (Base::*PVIBASEMEMFUNC)(int);
    typedef void (Derived::*PVIDERIVEMEMFUNC)(int);

int _tmain(int argc, _TCHAR* argv[])
{
    PVIBASEMEMFUNC pVIBaseMemFunc = &Base::setValue;
    PVIDERIVEMEMFUNC pVIDeriveMemFunc = static_cast<PVIDERIVEMEMFUNC>(pVIBaseMemFunc);

    PVVBASEMEMFUNC      pVVBaseMemFunc   = &Base::foobar;
    PVVDERIVEMEMFUNC    pVVDeriveMemFunc = static_cast<PVVDERIVEMEMFUNC>(pVVBaseMemFunc);

    Base baseObj;
    (baseObj.*pVIBaseMemFunc)(10);
    (baseObj.*pVVBaseMemFunc)();

    Derived deriveObj;
    (deriveObj.*pVIDeriveMemFunc)(20);
    (deriveObj.*pVVDeriveMemFunc)();

    return 0;
}

_deriveObj$ = -88
_baseObj$ = -60
_pVVDeriveMemFunc$ = -44
_pVVBaseMemFunc$ = -32
_pVIDeriveMemFunc$ = -20
_pVIBaseMemFunc$ = -8
_argc$ = 8
_argv$ = 12

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/eroswang/archive/2009/05/06/4153356.aspx

 解决方案

 这里的方案只支持一个模板参数，但如果一些能够如愿的话，随着更多的编译器完全实现C++标准，以后将会支持动态的模板参数，比如“…”形式的模板参数列表（参见《C++ Templates, The Complete Guide》），那时，我们就可以可以实现无需全部预定义的参数集合。（文中所有代码的注释为译者加，下同。）

 template < class Class, typename ReturnType, typename Parameter >
 class SingularCallBack
 {
   public:
//指向类成员函数的指针，用他来实现回调函数。
 typedef ReturnType (Class::*Method)(Parameter);
     //构造函数
     SingularCallBack(Class* _class_instance, Method _method)
     {
        class_instance = _class_instance;
       method        = _method;
     };
 //重载函数调用运算符()
     ReturnType operator()(Parameter parameter)
     {
        return (class_instance->*method)(parameter);
     };
     //与上面的()等价的函数，引入这个函数的原因见下文
     ReturnType execute(Parameter parameter)
     {
        return operator()(parameter);
 };
    private:
     Class*  class_instance;
     Method  method;
 };
 模板的使用

 模板（template）的使用非常方便，模板本身可被实例化为一个对象指针（object pointer）或者一个简单的类（class）。当作为对象指针使用时，C++有另外一个令人痛苦的限制：operator() 不可以在指针未被解引用的情况下调用，对于这个限制，一个简便的但却不怎么优雅的解决方法在一个模板内部增加一个execute方法（method），由这个方法从模板内部来调用operator()。除了这一点不爽之外，实例化SinglarCallBack为一个对象指针将可以使你拥有一个由回调组成的vector，或者任何其他类型的集合，这在事件驱动程序设计中是非常需要的。
 假设以下两个类已经存在，而且我们想让methodB作为我们的回调方法，从代码中我们可以看到当传递一个class A类的参数并调用methodB时，methodB会调用A类的output方法，如果你能在stdout上看到"I am class A :D"，就说明回调成功了。
 class A
 {
    public:
    void output()
     {
        std::cout << "I am class A :D" << std::endl;
     };
 };
 class B
 {
    public:
     bool methodB(A a)
     {
        a.output();
        return true;
     }
 };
 有两种方法可以从一个对象指针上调用一个回调方法，较原始的方法是解引用（dereference）一个对象指针并运行回调方法（即：operator()），第二个选择是运行execute方法。
 //第一种方法：
 A a;
 B b;
 SingularCallBack< B,bool,A >* cb;
 cb = new SingularCallBack< B,bool,A >(&b,&B::methodB);
 if((*cb)(a))
 {
    std::cout << "CallBack Fired Successfully!" << std::endl;
 }
 else
 {
   std::cout << "CallBack Fired Unsuccessfully!" << std::endl;
 }
 //第二种方法：
 A a;
 B b;
 SingularCallBack< B,bool,A >* cb;
 cb = new SingularCallBack< B,bool,A >(&b,&B::methodB);
 if(cb->execute(a))
 {
    std::cout << "CallBack Fired Successfully!" << std::endl;
 }
 else
 {
    std::cout << "CallBack Fired Unsuccessfully!" << std::endl;
 }
 下面的代码示范了怎样将一个模板实例化成一个普通的对象并使用之。
 A a;
 B b;
 SingularCallBack< B,bool,A >cb(&b,&B::methodB);
 {
    std::cout << "CallBack Fired Successfully!" << std::endl;
 }
 else
 {
    std::cout << "CallBack Fired Unsuccessfully!" << std::endl;
 }
 更复杂的例子，一个回调模板可以像下面这样使用：
 class AClass
 {
   public:
      AClass(unsigned int _id): id(_id){};
     ~AClass(){};
      bool AMethod(std::string str)
      {
         std::cout << "AClass[" << id << "]: " << str << std::endl;
         return true;
      };
    private:
     unsigned int id;
 };
 typedef SingularCallBack < AClass, bool, std::string > ACallBack;
 int main()
 {
    std::vector < ACallBack > callback_list;
    AClass a1(1);
    AClass a2(2);
    AClass a3(3);
    callback_list.push_back(ACallBack(&a1, &AClass::AMethod));
    callback_list.push_back(ACallBack(&a2, &AClass::AMethod));
    callback_list.push_back(ACallBack(&a3, &AClass::AMethod));
    for (unsigned int i = 0; i < callback_list.size(); i++)
    {
       callback_list[i]("abc");
    }
 
   for (unsigned int i = 0; i < callback_list.size(); i++)
   {
      callback_list[i].execute("abc");
   }
 
   return true;
}

下面这个例子比上面的又复杂一些，你可以混合从同一个公共基类（base class）上继承下来的不同的类到一个容器中，于是你就可以调用位于继承树的最底层的类的方法（most derived method）。（译者注，C++的多态机制）
class BaseClass
{
   public:
     virtual ~BaseClass(){};
     virtual bool DerivedMethod(std::string str){ return true; };
};

class AClass : public BaseClass
{
   public:
     AClass(unsigned int _id): id(_id){};
    ~AClass(){};
     bool AMethod(std::string str)
     {
        std::cout << "AClass[" << id << "]: " << str << std::endl;
        return true;
     };

     bool DerivedMethod(std::string str)
     {
        std::cout << "Derived Method AClass[" << id << "]: " << str << std::endl;
        return true;
     };

   private:
    unsigned int id;
};

class BClass : public BaseClass
{
   public:
    BClass(unsigned int _id): id(_id){};
    ~BClass(){};
     bool BMethod(std::string str)
     {
        std::cout << "BClass[" << id << "]: " << str << std::endl;
        return true;
     };

     bool DerivedMethod(std::string str)
     {
        std::cout << "Derived Method BClass[" << id << "]: " << str << std::endl;
        return true;
     };
   private:
    unsigned int id;

};

typedef SingularCallBack < BaseClass, bool, std::string > BaseCallBack;

int main()
{
   std::vector < BaseCallBack > callback_list;

   AClass a(1);
   BClass b(2);

   callback_list.push_back(BaseCallBack(&a, &BaseClass::DerivedMethod));
   callback_list.push_back(BaseCallBack(&b, &BaseClass::DerivedMethod));

   for (unsigned int i = 0; i < callback_list.size(); i++)
   {
      callback_list[i]("abc");
   }

   for (unsigned int i = 0; i < callback_list.size(); i++)
   {
      callback_list[i].execute("abc");
   }

   return true;
}

为简捷起见，与实例的验证（instance validation）相关的必要代码没有被包含进来，在实际的程序设计中，类实例的传递应该基于这样的结构：使用类似智能指针（smart pointer）的包装类。STL（标准模板库）提供了两个极好的选择：aotu_ptr以及它的后继：shared_ptr。Andrei Alexandrescu所著的《Modern C++ Design》一书也提供了一个面向策略设计（policy design oriented）的智能指针类。这三种方案中各有自己的优缺点，最终由用户自己来决定究竟那一种最适合他们的需要。

C++拷贝构造函数的几个细节(转自：http://grantren.javaeye.com/blog/43289)

#include "stdafx.h"
#include "stdio.h"
#include <iostream>
#include <string>


struct Test1 
{
    Test1() { }
    Test1(int i) { id = i; }
    Test1(const Test1& test)
    {
        id = test.id;
    }
    Test1& operator = (const Test1& test)
    {
        if(this == &test)
            return *this;
        id = test.id;
        return *this;
    }
    int id;
};

class Test2
{
public:
    Test2(){ m_pChar = NULL;}
    Test2(char *pChar) { m_pChar = pChar;}
    Test2(int num) 
    { 
        m_pChar = new char[num];
        for(int i = 0; i< num; ++i)
            m_pChar[i] = 'a';
        m_pChar[num-1] = '\0';
    }
    Test2(const Test2& test)
    {
        char *pCharT = m_pChar;

        m_pChar = new char[strlen(test.m_pChar)];
        strcpy(m_pChar, test.m_pChar);

        if(!pCharT)
            delete []pCharT;
    }
    Test2& operator = (const Test2& test)
    {
        if(this == &test)
            return *this;

        char *pCharT = m_pChar;
        m_pChar = new char[strlen(test.m_pChar)];
        strcpy(m_pChar, test.m_pChar);

        if(!pCharT)
            delete []pCharT;

        return *this;
    }
private:
    char *m_pChar;
};

int main(int argc, char* argv[])
{
    const Test1 ts(1); // Test1()
    const Test1* p_ts = &ts;
    const Test1 ts2(ts); //Test(const Test1& test)
    const Test1 ts3 = ts; //Test(const Test1& test)
    Test1 ts4; ts4 = ts;  //Test1& operator = (const Test1& test)

    Test2 t(5);
    Test2 t2(t);
    Test2 t3 = t2;
    Test2 t4; t4 = t;
    return 0;
}