1. 对于clr中的引用类型，定义变量时要用个^符，如"String^ var1"、"array<int>^ var2"、"array<String^>^ strarr"等，值类型不用。一个类型是值类型还是引用类型，取决于定义时用的是value struct/class还是ref struct/class。

2. 定义枚举要用enum struct/class, 否则是个原生枚举，C#里不能用。可指定数值类型和flags属性，如下：
    [FlagsAttribute]
    public enum class TestEnum : unsigned int
    {
       flag1 = 0x00000001,
       flag2 = 0x00000002,
    };

3. 原生字符串转换为托管字符串时，用：
    char* s1 = "native string1";
    wchar_t* s2 = L"native string2";
    String^ str1 = gcnew String( s1 );
    String^ str2 = gcnew String( s2 );
托管字符串转换为原生字符串时，用：
    pin_ptr<const wchar_t> p = PtrToStringChars( str );
如果需要ansi字符集，可再对p进行一些常规字符集转换。

4. 指针、句柄等与0进行赋值比较等操作时用nullptr，而不是NULL或0，后者会导致装箱等操作，如：
    HANDLE h = nullptr;
    if( h == nullptr ){}

5. C#中定义函数参数时的ref关键字在C++/CLI中用%号对应，如：
    void foo( String^% refstr );
out关键字，需要用[System::Runtime::InteropServices::OutAttribute]声明一下。

6. 数组空间初始化，用()而不是[]，也就是说它是一个函数调用，如
    array<int>^ arr = gcnew array<int>(100);
的作用是定义一个有100个元素的数组。

7. C++/CLI中很多地方不能用const、volatile等关键字，如果编译报错，就把它们去掉吧。

8. 尽量不要定义自己的DllMain，如果必须定义的话，DllMain中不要进行任何托管操作，否则极易导致死锁。可以"#pragma managed"编译指令，临时打开或关闭托管。

9. 暂时没有了，等想起来再补充。

    一直认为是①, 今天正在写的程序出错了才发现是②. 老天保佑以前的程序不出错吧. 这个错误一直没发现的原因有两点，一是我用do while循环比较少, 里面有continue的更少; 二是自己偷懒了, 想当然了, 其实以前怀疑过它的结果的, 但觉得①更符合逻辑就没有深究.

    犯了错误总是比较郁闷的, 不过能在一个上午认识到这样两个错误，也算收获不小了。

0. 什么是副作用（side effects）

特别的，C99和C++2003都指出，no effect的expression允许不被执行
An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object).

1. 什么是序列点（sequence points）

C99和C++2003对序列点的定义相同
At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place.

中文表述为，序列点是一些被特别规定的位置，要求在该位置前的evaluations所包含的一切副作用在此处均已完成，而在该位置之后的evaluations所包含的任何副作用都还没有开始

例如C/C++都规定完整表达式（full-expression）后有一个序列点

上面的代码中i = 0以及j = i都是一个完整表达式，;说明了表达式的结束，因此在;处有一个序列点，按照序列点的定义，要求在i = 0之后j = i之前的那个序列点上对i = 0的求值以及副作用全部结束（0被写入i中），而j = i的任何副作用都还没有开始。由于j = i的副作用是把i的值赋给j，而i = 0的副作用是把i赋值为0，如果i = 0的副作用发生在j = i之后，就会导致赋值后j的值是i的旧值，这显然是不对的

由序列点以及副作用的定义很容易看出，在一个序列点上，所有可能影响程序状态的动作均已完成，那这样能否推断出在一个序列点上一个程序的状态应该是确定的呢？！答案是不一定，这取决于我们代码的写法。但是，如果在一个序列点上程序的状态不能被确定，那么标准规定这样的程序是undefined behavior，稍后会解释这个问题

2. 表达式求值（evaluation of expressions）与副作用发生的相互顺序

C99和C++2003都规定
Except where noted, the order of evaluation of operands of individual operators and subexpressions of individual expressions, and the order in which side effects take place, is unspecified.

也就是说，C/C++都指出一般情况下在表达式求值过程中的操作数求值顺序以及副作用发生顺序是未说明的（unspecified）。为什么C/C++不详细定义这些顺序呢？原因是因为C/C++都是极端追求效率的语言，不规定这些顺序，是为了允许编译器有更大的优化余地，例如

编译器可以先计算(i++) + (j++) + (k++)的值，然后再对i、j、k各自加1，最后将i、j、k、x写回内存，这比每次完整的执行完++语义效率要高

3. 序列点对副作用的限制

C99和C++2003都有类似的如下规定
Between the previous and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored. The requirements of this paragraph shall be met for each allowable ordering of the subexpressions of a full expression; otherwise the behavior is undefined.

也就是说，在相邻的两个序列点之间，一个对象只允许被修改一次，而且如果一个对象被修改则在这两个序列点之间对该变量的读取的唯一目的只能是为了确定该对象的新值（例如i++，需要先读取i的值以确定i的新值是旧值+1）。特别的，标准要求任意可能的执行顺序都必须满足该条件，否则代码将是undefined behavior

之所以序列点会对副作用有如此的限制，就是因为C/C++标准没有规定子表达式求值以及副作用发生之间的顺序，例如

前面我提到在一个序列点上程序的状态不一定是确定的，原因就在于相邻的两个序列点之间可能会发生多个副作用，这些副作用的发生顺序是未指定的，如果多于一个的副作用用于修改同一个对象，例如示例代码i = ++i + 1;，则程序的结果是依赖于副作用发生顺序的；另外，如果某个表达式既修改了某个对象又需要读取该对象的值，且读取对象的值并不用于确定对象新值，则读取和修改两个动作的先后顺序也会导致程序的状态不能唯一确定
所幸的是，“在相邻的两个序列点之间，一个对象只允许被修改一次，而且如果一个对象被修改则在这两个序列点之间只能为了确定该对象的新值而读一次”这一强制规定保证了符合要求的程序在任何一个序列点位置上其状态都可以确定下来

注，由于对于UDT类型存在operator重载，函数语义会提供新的序列点，因此某些对于built-in类型是undefined behavior的表达式对于UDT确可能是良好定义的，例如

由此可见，常见的问题如printf("%d, %d", i++, i++)这种写法是错误的，这类问题作为笔试题或者面试题是没有任何意义的
类似的问题同样发生在cout << i++ << i++这种写法上，如果overload resolution选择成员函数operator<<，则等价于(cout.operator<<(i++)).operator<<(i++)，否则等价于operator<<(operator<<(cout, i++), i++)，如果i是built-in类型对象，这种写法跟foo(foo(0, i++), i++)的问题一致，都是未定义行为，因为存在某条执行路径使得i会在两个相邻的序列点之间被修改两次；如果i是UDT则该写法是良好定义的，跟i = i++一样，但是这种写法也是不推荐的，因为标准对于函数参数的求值顺序是unspecified，因此哪个i++先计算是不能预计的，这仍旧会带来移植性的问题，这种写法应该避免

4. 编译器的跨序列点优化

根据前述讨论可知，在同一个表达式内对于同一个变量i，允许的行为是
A. 不读取，改写一次，例如

对于情况B和C，编译器是有一定的优化权利的，它可以只读取一次变量的值然后直接使用该值多次

但是，当该变量是volatile-qualified类型时编译器允许的行为究竟如何目前还没有找到明确的答案，ctrlz认为如果在两个相邻序列点之间读取同一个volatile-qualified类型对象多次仍旧是undefined behavior，原因在于该读取动作有副作用且该副作用等价于修改该对象，RoachCock的意见是两个相邻的序列点之间读取同一个volatile-qualified类型应该是合法的，但是不能被优化成只读一次。一段在嵌入式开发中很常见的代码示例如下

如果编译器探测到foo()没有任何语句（包括foo()调用过的函数）对flag有过修改，则也许会把(2)优化成只在进入foo()的时候读一次flag的值而不是每次循环都读一次，这种跨序列点的优化很有可能导致死循环。但是这种代码在多线程编程中很常见，虽然foo()没有修改过flag，也许在另一个线程的某个函数调用中会修改flag以终止循环，为了避免这种跨序列点优化带来到错误，应该把flag声明为volatile bool，C++2003对volatile的说明如下
[Note: volatile is a hint to the implementation to avoid aggressive optimization involving the object because the value of the object might be changed by means undetectable by an implementation. See 1.9 for detailed semantics. In general, the semantics of volatile are intended to be the same in C++ as they are in C. ]

5. C99定义的序列点列表

— The call to a function, after the arguments have been evaluated.
— The end of the first operand of the following operators:
     logical AND && ;
     logical OR || ;
     conditional ? ;
     comma , .
— The end of a full declarator:
     declarators;
— The end of a full expression:
     an initializer;
     the expression in an expression statement;
     the controlling expression of a selection statement (if or switch);
     the controlling expression of a while or do statement;
     each of the expressions of a for statement;
     the expression in a return statement.
— Immediately before a library function returns.
— After the actions associated with each formatted input/output function conversion specifier.
— Immediately before and immediately after each call to a comparison function, and also between any call to a comparison function and any movement of the objects passed as arguments to that call.

6. C++2003定义的序列点列表

所有C99定义的序列点同样是C++2003所定义的序列点
此外，C99只是规定库函数返回之后有一个序列点，并没有规定普通函数返回之后有一个序列点，而C++2003则特别指出，进入函数（function-entry）和退出函数（function-exit）各有一个序列点，即拷贝一个函数的返回值之后同样存在一个序列点

需要特别说明的是，由于operator||、operator&&以及operator,可以重载，当它们使用函数语义的时候并不提供built-in operators所规定的那几个序列点，而仅仅只是在函数的所有参数求值后有一个序列点，此外函数语义也不支持||、&&的短路语义，这些变化很有可能会导致难以发觉的错误，因此一般不建议重载这几个运算符

7. C++2003中两处关于lvalue的修改对序列点的影响

在C语言中，assignment operators的结果是non-lvalue，C++2003则将assignment operators的结果改成了lvalue，目前尚不清楚这一改动对于built-in类型有何意义，但是它却导致了很多在合法的C代码在目前的C++中是undefined behavior，例如

显然按照C++2003的规定这个代码的行为是undefined，它在两个相邻的序列点之间修改了i两次

类似的问题同样发生在built-in类型的前缀++/--operators上，C++2003将前缀++/--的结果从rvalue修改为lvalue，这甚至导致了下列代码也是undefined behavior

同样是因为lvalue作为assignment operator的右操作数需要一个左值转换，该转换导致了一个读取动作且这个读取动作发生在修改对象之后

C++的这一改动显然是考虑不周的，导致了很多C语言的习惯写法都成了undefined behavior，因此Andrew Koenig在1999年的时候就向C++标准委员会提交了一个建议要求为assignment operators增加新的序列点，但是到目前为止C++标准委员会都还没有就该问题达成一致意见

1. 字节对齐

    每种cpu都有其特定的字长, 如目前最常见的32位cpu, 其字长就是32位(4字节), 即将普及的64位cpu, 字长就是64位(8字节). 而cpu对内存的访问总是从字长的整数倍开始, 以字长为单位的. 例如(假设是32位cpu, 下同)读一个32位整数, 如果其起始地址是0, 则只需一次内存操作; 但如果起始地址是1、2或3, 则需要两次操作来将相关的两个字都读出来, 再在cpu内部进行处理才行. 对x86cpu, 这样做仅会稍微降低一点效率, 但如果是某些其它类型的cpu则可能会有成千上万倍的效率损失, 甚至是程序根本无法运行.

    从以上的分析可以看出, 我们定义结构体时, 为了提高效率和可移植性, 应该尽量让cpu以最少的内存操作访问其任意一个成员. 例如对于第一个成员是char型, 第二个成员是int型的结构, 其体积应该是5字节, 但显然在这种情况下cpu对int型成员的访问要两次内存操作, 而不是最少的一次. 所以我们应该浪费一些空间, 在char型成员后面加上3个填充字节, 使int型成员的起始位置对齐cpu字长的整数倍. 不过, 一个像回事的程序会有大量结构定义, 如果都去人为计算, 手工填充, 工作量就太大了. 因此, 编译器特意设置了一个选项(在vs2005中, 它是项目属性|c/c++|code generation|struct member alignment)来配置默认的字节对齐方式, 你可以选择1、2、4、8或者16字节对齐. 如果你什么也没有选的话, 它的默认值是8. 当然, 编译器也并没有搞一刀切, 对于需要特殊处理的结构, 你还可以使用"#pragma pack"编译指令单独为其指定其合适的对齐方式. 注意, 虽然我们从cpu字长引出了编译器的字节对齐, 但它们是两个不同的概念, 一定不要弄混. 从某种意义上, 你可以把字节对齐理解为: 我的程序将运行在字长是这个数值的cpu上.

2. 简单结构

    这里所说的简单结构, 是指仅由编译器内置类型构成的结构. 我们已经知道, 计算其体积, 需要其字节对齐设置, 这里假设其值是N. 则(有点拗口, 多读几遍):
    简单结构的大小, 是其符合"使cpu在任意情况下, 访问其任意成员的内存操作次数不大于'(sizeof(此成员) + N - 1)/N'(这里的除法使用的是C/C++整数除法的语意)"的所有内存布局中, 体积最小的那个占用的字节数. 
    例如结构：
    struct A         和         struct B
    {                           {
        char c;                     double d;
        double d;                   char c;
    };                          };
其sizeof的结果与N的对应关系应该是:

3. 复合结构

     与简单结构相对, 复合结构就是指那些部分或全部成员也是结构的结构. 其实没有必要把它单独列出来的, 因为其大小的计算方法与简单结构完全一样. 唯一要注意的就是: 对其每个成员的大小的计算要按定义这个成员的类型时的字节对齐来进行, 而不能按定义这个复合结构时的对齐设置. 例如:
    #pragma pack( push, 8 )
    struct A
    {
        char c;
         double d;
    };
    #pragma pack( 1 )
    struct B
    {
        char c;
         A a;
    };
    #pragma pack( pop )
sizeof(A)和sizeof(B), 将分别是16和17, 而不是16和10.

4. 特殊情况

    结构体的大小还有几种特殊情况, 一是空结构, 即没有任何成员的结构, 这种情况, 编译器规定其大小是1; 二是如果结构有虚函数, 则它会包含一个虚函数表指针(vfptr, 但这只是一般情况, 具体取决与编译器实现), 它的大小等于cpu字长, 但由于不能直接从定义中看出来, 你数的时候一定不要把它忘了; 还有就是虚拟继承等情况, 不过它们的结果与编译器实现关联太严重, 并且通常也碰不到, 这里就不做讨论了.

PS: 只是大概想了这么多, 如果哪里说错了, 欢迎大家批评指正.

void foo( char bar[100] )
{
    printf( "%d ", sizeof(bar) );
}


int main( int argc, char** argv )
{
    char bar[100];
    foo( bar );
    return 0;
}

一直认为输出应该是100, 但实际却是4(即sizeof(char*)).
现在，唯一让我庆幸的是我在函数参数中使用数组, 并且依赖sizeof的结果的时候极少.

	void foo( int a );
void foo( int& a );
……
int m = 10;
foo( m );     // 错误，二义性

	//以下代码是甲写的
void foo( int a );
//以下代码是乙写的
int m = 10;
foo( m );

	//以下代码是甲写的
class Base1
{
public:
void doIt();
};
class Base2
{
private:
void doIt();
};
//以下代码是乙写的
// Devried没有定义自己的doIt
class Devried : public Base1, public Base2
{
};
……
Devried d;
d.doIt();				//①

	d.Base1::doIt();

2. 不完备的C++类型系统

	//假设sometype和整数是兼容类型
sometype m = 10, n = 11;
sometype& r = m;
r = n;                       //①

3. 增加一个“取引用”运算符又如何？

	int m = 10, n = 11;
int& r;
r = @m;		//让r成为m的引用
r = n;		//把n的值赋给r
r = @n;		//让r成为n的引用

	int m = 10;
int& r1 = @m;
int n = $r1;		//①
int$ r2 = @n;
r2 = $r1; 		//② 把r1引用的值赋给r2
r2 = r1;		//让r2也去引用m

	//array是程序员自定义的整形数组的实例
array[0] = 10;
int n = array[1];        //①
int& r = @n;
array[3] = r;            //②

	array[3] = $r;

	//array是程序员自定义的整形数组的实例
array[0] = 10;
int n = $array[1];        //①
int& r = @n;
array[3] = $r;            //②

	//array是程序员自定义的整形数组的实例
array[0] = 10;
int n = array[1];
int& r = @n;
array[3] = r;		//①

	//array是程序员自定义的整形数组的实例
array[0] = 10;
int& r = @array[1];	//①
int n = array[2];
r = n;               	//②

	void foo( int a );
void bar( int& a );
foo( array[0] );		//array是内置数组类型
foo( $array[0] );		//array是自定义数组类型
bar( @array[0] );		//array是内置数组类型
bar( array[0] );		//array是自定义数组类型

4. 结论

注释：

作者：Vishal Kochhar   查看原文       翻译：局部变量

注：本文在网上已经有几个译本，但都不完整，所以我决定自己把它翻译过来。虽然力求信、雅、达，但鉴于这是我的第一次翻译经历，不足之处敬请谅解并指出。

    与传统语言相比，C++的一项革命性创新就是它支持异常处理。传统的错误处理方式经常满足不了要求，而异常处理则是一个极好的替代解决方案。它将正常代码和错误处理代码清晰的划分开来，程序变得非常干净并且容易维护。本文讨论了编译器如何实现异常处理。我将假定你已经熟悉异常处理的语法和机制。本文还提供了一个用于VC++的异常处理库，要用库中的处理程序替换掉VC++提供的那个，你只需要调用下面这个函数：

install_my_handler();

结构化异常处理—概述

    在本文的讨论中，我认为异常或者是被明确的抛出的，或者是由于除零溢出、空指针访问等引起的。当它发生时会产生一个中断，接下来控制权就会传递到操作系统的手中。操作系统将调用异常处理程序，检查从异常发生位置开始的函数调用序列，进行堆栈展开和控制权转移。Windows定义了结构“EXCEPTION_REGISTRATION”，使我们能够向操作系统注册自己的异常处理程序。

struct EXCEPTION_REGISTRATION
{
EXCEPTION_REGISTRATION* prev;
DWORD handler;
}; 

    注册时，只需要创建这样一个结构，然后把它的地址放到FS段偏移0的位置上去就行了。下面这句汇编代码演示了这一操作：

mov FS:[0], exc_regp

prev字段用于建立一个EXCEPTION_REGISTRATION结构的链表，每次注册新的EXCEPTION_REGISTRATION时，我们都要把原来注册的那个的地址存到prev中。
    那么，那个异常回调函数长什么样呢？在excpt.h中，windows定义了它的原形：

EXCEPTION_DISPOSITION (*handler)(
_EXCEPTION_RECORD *ExcRecord,
void* EstablisherFrame,
_CONTEXT *ContextRecord,
void* DispatcherContext);  

不要管它的参数和返回值，我们先来看一个简单的例子。下面的程序注册了一个异常处理程序，然后通过除以零产生了一个异常。异常处理程序捕获了它，打印了一条消息就完事大吉并退出了。

#include <iostream>
#include <windows.h>
using std::cout;
using std::endl;
struct EXCEPTION_REGISTRATION
{
EXCEPTION_REGISTRATION* prev;
DWORD handler;
};
EXCEPTION_DISPOSITION myHandler(
_EXCEPTION_RECORD *ExcRecord,
void * EstablisherFrame,
_CONTEXT *ContextRecord,
void * DispatcherContext)
{
cout << "In the exception handler" << endl;
cout << "Just a demo. exiting..." << endl;
exit(0);
return ExceptionContinueExecution; //不会运行到这
}
int  g_div = 0;
void bar()
{
//初始化一个EXCEPTION_REGISTRATION结构
EXCEPTION_REGISTRATION reg, *preg = &reg;
reg.handler = (DWORD)myHandler;
//取得当前异常处理链的“头”
DWORD prev;
_asm
{
mov EAX, FS:[0]
mov prev, EAX
}
reg.prev = (EXCEPTION_REGISTRATION*) prev;
//注册！
_asm
{
mov EAX, preg
mov FS:[0], EAX
}
//产生一个异常
int  j = 10 / g_div;  //异常，除零溢出
}
int  main()
{
bar();
return 0;
}
/*-------输出-------------------
In the exception handler
Just a demo. exiting...
---------------------------------*/

    注意EXCEPTION_REGISTRATION必须定义在栈上，并且必须位于比上一个结点更低的内存地址上，windows对此有严格要求，达不到的话，它就会立刻终止进程。

函数和堆栈

    堆栈是用来保存局部对象的连续内存区。更明确的说，每个函数都有一个相关的栈桢（stack frame）来保存它所有的局部对象和表达式计算过程中用到的临时对象，至少理论上是这样的。但现实中，编译器经常会把一些对象放到寄存器中以便能以更快的速度访问。堆栈是一个处理器（CPU）层次的概念，为了操纵它，处理器提供了一些专用的寄存器和指令。
    图1是一个典型的堆栈，它示出了函数foo调用bar，bar又调用widget时的情景。请注意堆栈是向下增长的，这意味着新压入的项的地址低于原有项的地址。

    通常编译器使用EBP寄存器来指示当前活动的栈桢。本例中，CPU正在运行widget，所以图中的EBP指向了widget的栈桢。编译器在编译时将所有局部对象解析成相对于栈桢指针（EBP）的固定偏移，函数则通过栈桢指针来间接访问局部对象。举个例子，典型的，widget访问它的局部变量时就是通过访问栈桢指针以下的、有着确定位置的几个字节来实现的，比如说EBP-24。
    上图中也画出了ESP寄存器，它叫栈指针，指向栈的最后一项。在本例中，ESP指着widget的栈桢的末尾，这也是下一个栈桢（如果它被创建的话）的开始位置。
    处理器支持两种类型的栈操作：压栈（push）和弹栈（pop）。比如，

pop EAX

的作用是从ESP所指的位置读出4字节放到EAX寄存器中，并把ESP加上（记住，栈是向下增长的）4（在32位处理器上）；类似的，

push EBP

的作用是把ESP减去4，然后将EBP的值放到ESP指向的位置中去。
    编译器编译一个函数时，会在它的开头添加一些代码来为其创建并初始化栈桢，这些代码被称为序言（prologue）；同样，它也会在函数的结尾处放上代码来清除栈桢，这些代码叫做尾声（epilogue）。
    一般情况下，序言是这样的：

Push EBP     ; 把原来的栈桢指针保存到栈上
Mov EBP, ESP ; 激活新的栈桢
Sub ESP, 10  ; 减去一个数字，让ESP指向栈桢的末尾

    第一条指令把原来的栈桢指针EBP保存到栈上；第二条指令通过让EBP指向主调函数的EBP的保存位置来激活被调函数的栈桢；第三条指令把ESP减去了一个数字，这样ESP就指向了当前栈桢的末尾，而这个数字是函数要用到的所有局部对象和临时对象的大小。编译时，编译器知道函数的所有局部对象的类型和“体积”，所以，它能很容易的计算出栈桢的大小。
    尾声所做的正好和序言相反，它必须把当前栈桢从栈上清除掉：

Mov ESP, EBP
Pop EBP      ; 激活主调函数的栈桢
Ret          ; 返回主调函数

它让ESP指向主调函数的栈桢指针的保存位置（也就是被调函数的栈桢指针指向的位置），弹出EBP从而激活主调函数的栈桢，然后返回主调函数。
    一旦CPU遇到返回指令，它就要做以下两件事：把返回地址从栈中弹出，然后跳转到那个地址去。返回地址是主调函数执行call指令调用被调函数时自动压栈的。Call指令执行时，会先把紧随在它后面的那条指令的地址（被调函数的返回地址）压入栈中，然后跳转到被调函数的开始位置。图2更详细的描绘了运行时的堆栈。如图所示，主调函数把被调函数的参数也压进了堆栈，所以参数也是栈桢的一部分。函数返回后，主调函数需要移除这些参数，它通过把所有参数的总体积加到ESP上来达到目的，而这个体积可以在编译时知道：

Add ESP, args_size

当然，也可以把参数的总体积写在被调函数的返回指令的后面，让被调函数去移除参数，下面的指令就在返回主调函数前从栈中移去了24个字节：

Ret 24

取决于被调函数的调用约定（call convention），这两种方式每次只能用一个。你还要注意的是每个线程都有自己独立的堆栈。

C++和异常

    回忆一下我在第一节中介绍的EXCEPTION_REGISTRATION结构，我们曾用它向操作系统注册了发生异常时要被调用的回调函数。VC++也是这么做的，不过它扩展了这个结构的语义，在它的后面添加了两个新字段：

struct EXCEPTION_REGISTRATION
{
EXCEPTION_REGISTRATION* prev;
DWORD handler;
int id;
DWORD ebp;
}; 

C++和异常—2

    图4是funcinfo的布局，注意这里的字段名可能与VC++编译器实际使用的不完全一致，而且我也只给出了和我们的讨论相关的字段。堆栈展开表（unwind table）的结构留到下节再讨论。

    异常处理程序在函数中查找catch块时，它首先要判断异常发生的位置是否在当前函数（发生异常的那个函数）的一个try块中。是则查找与此try块相关的catch块表，否则直接返回。
    先来看看它怎样找try块。编译时，编译器给每个try块都分配了start id和end id。通过funcinfo结构，异常处理程序可以访问这两个id，见图4。编译器为函数中的每个try块都生成了相关的数据结构。
    上一节中，我说过VC++给EXCEPTION_REGISTRATION结构加上了一个id字段。回忆一下图3，这个结构位于函数的栈桢上。异常发生时，处理程序读出这个值，看它是否在try块的两个id确定的区间[start id，end id]中。是的话，异常就发生在这个try块中；否则继续查看try块表中的下一个try块。
    谁负责更新id的值，它的值又应该是什么呢？原来，编译器会在函数的多个位置安插代码来更新id的值，以反应程序的实时运行状态。比如说，编译器会在进入try块的地方加上一条语句，把try块的start id写到栈桢上。
    找到try块后，处理程序就遍历与其关联的catch块表，看是否有对当前异常感兴趣的catch块。在try块发生嵌套时，异常将既源于内层try块，也源于外层try块。这种情况下，处理程序应该按先内后外的顺序查找catch块。但它其实没必要关心这些，因为，在try块表中，VC++总是把内层try块放在外层try块的前面。
    异常处理程序还有一个难题就是“如何根据catch块的相关数据结构判断这个catch块是否愿意处理当前异常”。这是通过比较异常的类型和catch块的参数的类型来完成的。例如下面这个程序：

void foo()
{
try
{
throw E();
}
catch(H)
{
//.
}
}  

如果H和E的类型完全相同的话，catch块就要捕获这个异常。这意味着处理程序必须在运行时进行类型比较，对C等语言来说，这是不可能的,因为它们无法在运行时得到对象的类型。C++则不同，它有了运行时类型识别（runtime type identification，RTTI），并提供了运行时类型比较的标准方法。C++在标准头文件中定义了type_info类，它能在运行时代表一个类型。catch块数据结构的第二个字段（ptype_info，见图4）是一个指向type_info结构的指针，它在运行时就代表catch块的参数类型。type_info也重载了==运算符，能够指出两种类型是否完全相同。这样，异常处理程序只要比较（调用==运算符）catch块参数的type_info（可以通过catch块的相关数据结构来访问）和异常的type_info是否相同，就能知道catch块是不是愿意捕获当前异常了。
    catch块的参数类型可以通过funcinfo结构得到，但异常的type_info从哪来呢？当编译器碰到

throw E();

这条语句时，它会为异常生成一个excpt_info结构，如图5所示。还是要提醒你注意这里用的名字可能与VC++使用的不一致，而且仍然只有与我们的讨论相关的字段。从图中可以看出，异常的type_info可以通过excpt_info结构得到。由于异常处理程序需要拷贝异常对象（在调用catch块之前），也需要消除掉它（在调用catch块之后），所以编译器在这个结构中同时提供了异常的拷贝构造函数、大小和析构函数的信息。

    在catch块的参数是基类，而异常是派生类时，异常处理程序也应该调用catch块。然而，这种情况下，比较它们的type_info绝对是不相等，因为它们本来就不是相同的类型。而且，type_info类也没有提供任何其他函数或运算符来指出一个类是另一个类的基类。但异常处理程序还必须得去调用catch块！为了解决这个问题，编译器只能为处理程序提供更多的信息：如果异常是派生类，那么etypeinfo_table（通过excpt_info访问）将包含多个指向etype_info（扩展了type_info，这个名字是我启的）的指针，它们分别指向了各个基类的etype_info。这样，处理程序就可以把catch块的参数和所有这些type_info比较，只要有一个相同，就调用catch块。
    在结束这一部分之前，还有最后一个问题：异常处理程序是怎么知道异常和excpt_info结构的？下面我就要回答这个问题。
    VC++会把throw语句翻译成下面的样子：

//throw E(); //编译器会为E生成excpt_info结构
E e = E(); //在栈上创建异常
_CxxThrowException(&e, E_EXCPT_INFO_ADDR);

__CxxThrowException会把控制权连带它的两个参数都交给操作系统（控制权转移是通过软件中断实现的，请参见RaiseException）。而操作系统，在为调用异常回调函数做准备时，会把这两个参数打包到一个_EXCEPTION_RECORD结构中。接着，它从EXCEPTION_REGISTRATION链表的头结点（由FS:[0]指向）开始，依次调用各节点的异常处理程序。而且，指向当前EXCEPTION_REGISTRATION结构的指针也会作为异常处理程序的第二个参数出现。前面已经说过，VC++中的每个函数都在栈上创建并注册了EXCEPTION_REGISTRATION结构。所以传递这个参数可以让处理程序知道很多重要信息，比如说：EXCEPTION_REGISTRATION的id字段（用于查找catch块）、函数的栈桢（用于清理栈桢）和EXCEPTION_REGISTRATION结点在异常链表中的位置（用于堆栈展开）等。第一个参数是指向_EXCEPTION_RECORD结构的指针，通过它可以找到异常和它的excpt_info结构。下面是excpt.h中定义的异常回调函数的原型：

EXCEPTION_DISPOSITION (*handler)(
_EXCEPTION_RECORD* ExcRecord,
void* EstablisherFrame,
_CONTEXT *ContextRecord,
void* DispatcherContext);

后两个参数和我们的讨论关系不大。函数的返回值是一个枚举类型（也在excpt.h中定义），我前面已经说过，如果处理程序找不到catch块，它就会向系统返回ExceptionContinueSearch，对本文而言，我们只要知道这一个返回值就行了。_EXCEPTION_RECORD结构是在winnt.h中定义的：

struct _EXCEPTION_RECORD
{
DWORD ExceptionCode;
DWORD ExceptionFlags;
_EXCEPTION_RECORD* ExcRecord;
PVOID ExceptionAddress;
DWORD NumberParameters;
DWORD ExceptionInformation[15];
}EXCEPTION_RECORD; 

清理栈桢

    C++标准明确指出：堆栈展开工作必须调用异常发生时所有生存的局部对象的析构函数。如下面的代码：

int g_i = 0;
void foo()
{
T o1, o2;
{
T o3;
}
10/g_i; //这里会发生异常
T o4;
//...
} 

foo有o1、o2、o3、o4四个局部对象，但异常发生时，o3已经“死亡”，o4还未“出生”，所以异常处理程序应该只调用o1和o2的析构函数。 
    前面已经说过，编译器会在函数的很多地方安插代码来记录当前的运行状态。实际上，编译器在函数中设置了一些关键区域，并为它们分配了id，进入关键区域时要记录它的id，退出时恢复前一个id。try块就是一个例子,其id就是start id。所以，在try块的入口，编译器会把它的start id记到栈桢上去。局部对象从创建到销毁也确定了一个关键区域，或者，换句话说，编译器给每个局部对象分配了唯一的id，例如下面的程序：

void foo()
{
T t1;
//.
} 

编译器会在t1的定义后面（也就是t1创建以后）,把它的id写到栈桢上：

void foo()
{
T t1;
_id = t1_id; //编译器插入的语句
//.
} 

上面的_id是编译器偷偷创建的局部变量，它的位置与EXCEPTION_REGISTRATION的id字段重叠。类似的，在调用对象的析构函数前，编译器会恢复前一个关键区域的id。
    清理栈桢时，异常处理程序读出id的值（通过EXCEPTION_REGISTRATION结构的id字段或栈桢指针EBP下面的4个字节来访问）。这个id可以表明，函数在运行到与它相关联的那个点之前没有发生异常。所有在这一点之前定义的对象都已初始化，应该调用这些对象中的一部分或全部对象的析构函数。请注意某些对象是属于子块（如前面代码中的o3）的，发生异常时可能已经销毁了，不应该调用它们的析构函数。
    编译器还为函数生成了另一个数据结构——堆栈展开表（unwindtable，我启的名字），它是一个unwind结构的数组，可通过funcinfo来访问，如图4所示。函数的每个关键区域都有一个unwind结构，这些结构在展开表中出现的次序和它们所对应的区域在函数中的出现次序完全相同。一般unwind结构也会关联一个对象（别忘了，每个对象的定义都开辟了关键区域，并有id与其对应），它里面有如何销毁这个对象的信息。每当编译器碰到对象定义，它就生成一小段代码，这段代码知道对象在栈桢上的地址（就是它相对于栈桢指针的偏移），并能销毁它。unwind结构中有一个字段用于保存这段代码的入口地址：

typedef void (*CLEANUP_FUNC)();
struct unwind
{
int prev;
CLEANUP_FUNC cf;
}; 

try块对应的unwind结构的cf字段是空值NULL，因为没有与它对应的对象，所以也没有东西需要它去销毁。通过prev字段，这些unwind结构也形成了一个链表。异常处理程序清理栈桢时，会读取当前的id值，以它为索引取得展开表中对应的项，并调用其第二个字段指向的清理代码，这样，那个与之关联的对象就被销毁了。然后，处理程序将以当前unwind结构的prev字段为索引，继续在展开表中找下一个unwind结构，调用其清理代码。这一过程将一直重复，直到链表的结尾（prev的值是-1）。图6画出了本节开始时提到的那段代码的堆栈展开表。

    现在把new运算符也加进来，对于下面的代码：

T* p = new T();

实现

    本节我们讨论其他三个有待详细解释的问题：
a) 如何安装异常处理程序
b) catch块重新抛出异常或抛出新异常时应该如何处理
c) 如何对所有线程提供异常处理支持
    随同本文，有一个演示项目，查看其中的readme.txt文件可以得到一些编译方面的帮助①。
    第一项任务是安装异常处理程序，也就是把VC++的处理程序替换掉。从前面的讨论中，我们已经清楚地知道__CxxFrameHandler函数是VC++所有异常处理工作的入口。编译器为每个函数都生成一段代码，它们在发生异常时被调用，把相应的funcinfo结构的指针交给__CxxFrameHandler。
    install_my_handler()函数会改写__CxxFrameHandler的入口处的代码，让程序跳转到my_exc_handler()函数。不过，__CxxFrameHandler位于只读的内存页，对它的任何写操作都会导致访问违例，所以必须首先用VirtualProtectEx把该内存页的保护方式改成可读写，等改写完毕后，再改回只读。写入的数据是一个jmp_instr结构。

//install_my_handler.cpp
#include <windows.h>
#include "install_my_handler.h"
//C++默认的异常处理程序
extern "C"
EXCEPTION_DISPOSITION __CxxFrameHandler(
struct _EXCEPTION_RECORD* ExceptionRecord,
void* EstablisherFrame,
struct _CONTEXT* ContextRecord,
void* DispatcherContext
);
namespace
{
char cpp_handler_instructions[5];
bool saved_handler_instructions = false;
}
namespace my_handler
{
//我的异常处理程序 EXCEPTION_DISPOSITION
my_exc_handler(
struct _EXCEPTION_RECORD *ExceptionRecord,
void * EstablisherFrame,
struct _CONTEXT *ContextRecord,
void * DispatcherContext
)  throw();
#pragma pack(push, 1)
struct jmp_instr
{
unsigned char jmp;
DWORD offset;
};
#pragma pack(pop)
bool WriteMemory(void* loc, void* buffer, int size)
{
HANDLE hProcess = GetCurrentProcess();
//把包含内存范围[loc，loc+size]的页面的保护方式改成可读写
DWORD old_protection;
BOOL ret = VirtualProtectEx(hProcess, loc, size, PAGE_READWRITE, &old_protection);
if(ret == FALSE)
return false;
ret = WriteProcessMemory(hProcess, loc, buffer, size, NULL);
//恢复原来的保护方式
DWORD o2;
VirtualProtectEx(hProcess, loc, size, old_protection, &o2);
return (ret == TRUE);
}
bool ReadMemory(void* loc, void* buffer, DWORD size)
{
HANDLE hProcess = GetCurrentProcess();
DWORD bytes_read = 0;
BOOL ret = ReadProcessMemory(hProcess, loc, buffer, size, &bytes_read);
return (ret == TRUE && bytes_read == size);
}
bool install_my_handler()
{
void* my_hdlr = my_exc_handler; void* cpp_hdlr = __CxxFrameHandler;
jmp_instr jmp_my_hdlr;
jmp_my_hdlr.jmp = 0xE9;
//从__CxxFrameHandler+5开始计算偏移，因为jmp指令长5字节
jmp_my_hdlr.offset = reinterpret_cast<char*>(my_hdlr) - (reinterpret_cast<char*>(cpp_hdlr) + 5);
if(!saved_handler_instructions)
{
if(!ReadMemory(cpp_hdlr, cpp_handler_instructions, sizeof(cpp_handler_instructions)))
return false;
saved_handler_instructions = true;
}
return WriteMemory(cpp_hdlr, &jmp_my_hdlr, sizeof(jmp_my_hdlr));
}
bool restore_cpp_handler()
{
if(!saved_handler_instructions)
return false;
else
{
void* loc = __CxxFrameHandler;
return WriteMemory(loc, cpp_handler_instructions, sizeof(cpp_handler_instructions));
}
}
}

    编译指令#pragma pack(push, 1)告诉编译器不要在jmp_instr结构中填充任何用于对齐的空间。没有这条指令，jmp_instr的大小将是8字节，而我们需要它是5字节。
    现在重新回到异常处理这个主题上来。调用catch块时，它可能重新抛出异常或抛出新异常。前一种情况下，异常处理程序必须继续传播（propagate）当前异常；后一种情况下，它需要在继续之前销毁原来的异常。此时，处理程序要面对两个难题：“如何知道异常是源于catch块还是程序的其他部分”和“如何跟踪原来的异常”。我的解决方法是：在调用catch块之前，把当前异常保存在exception_storage对象中，并注册一个专用于catch块的异常处理程序——catch_block_protector。调用get_exception_storage()函数，就能得到exception_storage对象：

exception_storage* p = get_exception_storage();
p->set(pexc, pexc_info);
注册 catch_block_protector;
调用catch块; //....

    这样，当catch块（重新）抛出异常时，程序将会执行catch_block_protector。如果是抛出了新异常，这个函数可以从exception_storage对象中分离出前一个异常并销毁它；如果是重新抛出原来的异常（可以通过ExceptionInformation数组的前两个元素知道是新异常还是旧异常，后一种情况下着两个元素都是0，参见下面的代码），就通过拷贝ExceptionInformation数组来继续传播它。下面的代码就是catch_block_protector()函数的实现。

//-------------------------------------------------------------------
// 如果这个处理程序被调用了，可以断定是catch块（重新）抛出了异常。
// 异常处理程序（my_handler）在调用catch块之前注册了它。其任务是判断
// catch块抛出了新异常还是重新抛出了原来的异常，并采取相应的操作。
// 在前一种情况下，它需要销毁传递给catch块的前一个异常对象；在后一种
// 情况下，它必须找到原来的异常并将其保存到ExceptionRecord中供异常
// 处理程序使用。
//-------------------------------------------------------------------
EXCEPTION_DISPOSITION catch_block_protector(
_EXCEPTION_RECORD* ExceptionRecord,
void* EstablisherFrame,
struct _CONTEXT *ContextRecord,
void* DispatcherContext
) throw ()
{
EXCEPTION_REGISTRATION *pFrame;
pFrame= reinterpret_cast<EXCEPTION_REGISTRATION*>(EstablisherFrame);
if(!(ExceptionRecord->ExceptionFlags & (_EXCEPTION_UNWINDING | _EXCEPTION_EXIT_UNWIND)))
{
void *pcur_exc = 0, *pprev_exc = 0;
const excpt_info *pexc_info = 0, *pprev_excinfo = 0;
exception_storage* p = get_exception_storage();
pprev_exc = p->get_exception();
pprev_excinfo = p->get_exception_info();
p->set(0, 0);
bool cpp_exc = ExceptionRecord->ExceptionCode == MS_CPP_EXC;
get_exception(ExceptionRecord, &pcur_exc);
get_excpt_info(ExceptionRecord, &pexc_info);
if(cpp_exc && 0 == pcur_exc && 0 == pexc_info) //重新抛出
{
ExceptionRecord->ExceptionInformation[1] = reinterpret_cast<DWORD>(pprev_exc);
ExceptionRecord->ExceptionInformation[2] = reinterpret_cast<DWORD>(pprev_excinfo);
}
else
{
exception_helper::destroy(pprev_exc, pprev_excinfo);
}
}
return ExceptionContinueSearch;
}

    下面是get_exception_storage()函数的一个实现：

exception_storage* get_exception_storage()
{
static exception_storage es;
return &es;
} 

    在单线程程序中，这是一个完美的实现。但在多线程中，这就是个灾难了，想象一下多个线程访问它，并把异常对象保存在里面的情景吧。由于每个线程都有自己的堆栈和异常处理链，我们需要一个线程安全的get_exception_storage实现：每个线程都有自己单独的exception_storage，它在线程启动时被创建，并在结束时被销毁。Windows提供的线程局部存储（thread local storage，TLS）可以满足这个要求，它能让每个线程通过一个全局键值来访问为这个线程所私有的对象副本，这是通过TlsGetValue()和TlsSetValue这两个API来完成的。
    Excptstorage.cpp中给出了get_exception_storage()函数的实现。它会被编译成动态链接库，因为我们可以籍此知道线程的创建和退出——系统在这两种情况下都会调用所有（当前进程加载的）dll的DllMain()函数，这让我们有机会创建特定于线程的数据，也就是exception_storage对象。

//excptstorage.cpp
#include "excptstorage.h"
#include <windows.h>
namespace
{
DWORD dwstorage;
}
namespace my_handler
{
__declspec(dllexport) exception_storage* get_exception_storage() throw ()
{
void * p = TlsGetValue(dwstorage);
return reinterpret_cast <exception_storage*>(p);
}
}
BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved )
{
using my_handler::exception_storage;
exception_storage *p;
switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
//主线程（第一个线程）不会收到DLL_THREAD_ATTACH通知，所以，
//与其相关的操作也放在这了
dwstorage = TlsAlloc();
if (-1 == dwstorage)
return FALSE;
p = new exception_storage();
TlsSetValue(dwstorage, p);
break ;
case DLL_THREAD_ATTACH:
p = new exception_storage();
TlsSetValue(dwstorage, p);
break;
case DLL_THREAD_DETACH:
p = my_handler::get_exception_storage();
delete p;
break ;
case DLL_PROCESS_DETACH:
p = my_handler::get_exception_storage();
delete p;
break ;
}
return TRUE;
}  

结论

注释和参考资料