副标题#e#
为了验证前面提到过的范例动态转换(即dynamic_cast转换)，以及工具范例的强制转换。我们操作前面界说的C041、C042及C082类来举办验证。
运行下列代码：
c082.C041::c_ = 0x05;
PRINT_VTABLE_ITEM(c041, 0, 0)
PRINT_DETAIL(C041, ((C041)c082))
PRINT_VTABLE_ITEM(((C041)c082), 0, 0)
PRINT_VTABLE_ITEM(c082, 5, 0)
C042 * pt = dynamic_cast<C042*>(&c082);
PRINT_VTABLE_ITEM(*pt, 0, 0)
第2行和第5行是为了比较利便而打印原工具中的信息。第3、4行把C082工具范例举办强制转换并别离打印转换后的工具内存信息及虚表信息。第6行我们用dynamic_cast举办了一次动态范例转换，从子类的指针转型为右父类的指针，再把指针指向的工具的信息打印出来。
功效为：
c041 : objadr:0012FA74 vpadr:0012FA74 vtadr:0045B364 vtival(0):0041DF1E
The detail of C041 is 64 b3 45 00 05
((C041)c082) : objadr:0012F2A3 vpadr:0012F2A3 vtadr:0045B364 vtival(0):0041DF1E
c082 : objadr:0012FA50 vpadr:0012FA55 vtadr:0045B36C vtival(0):0041D483
*pt : objadr:0012FA55 vpadr:0012FA55 vtadr:0045B36C vtival(0):0041D483
首先我们较量最后两行，从objadr列我们可以知道pt指向的并不是c082工具的起始地点，而是指向了c082的第2个虚表指针的地址地点(因为最后一行的objadr值便是倒数第2行的vpadr的值)。倒数第二行的vpadr值是c082工具的第2个虚表指针(我们在输出时指定了偏移值5)。而这个地点正是c082工具中属于从C042类担任而来的部门，即在进动作态范例转换时，除了改变范例信息，编译器还调解了指针的位置，以确保转换语义的正确性。所以我们可以知道，对指向有巨大担任布局的类工具的指针举办范例转换(一般在担任树中向上或向下转换)时，必需利用dynamic_cast，它会正确的处理惩罚指针位置的调解，假如转换是犯科的，它会返回一个NULL指针。利用dynamic_cast时记得要做这个查抄，文中为了大略把这些查抄省去了。这种查抄可以通过宏来界说，以便于在release版中去掉，提高效率。
#p#副标题#e#
再将((C041)c082)和c082两行的输出举办比较，可以发明对工具举办向上的范例强制转换实际上编译器生成了一个新的姑且工具，因为它们的objadr列纷歧样了，这表白它们已经不是同一个工具。再调查 c041、((C041)c082)及c082三行的vtadr和vtival(0)，前两行对比是一样的，尔后两行对比就纷歧样了。这也说明编译器在处理惩罚强制转换时，实际上是new了一个新的C041工具出来。因为工具的强制范例转换不象指针的动态范例转换，指针的动态范例转换同时要确保多态的语义，所以只需要调解指针位置。而工具强制范例转换，还要调解虚表中的条目值，因为工具范例转换不需要多态的行为。c082类的第一个虚表的第一个条目中存放的是 C082::foo()函数的地点，做了工具范例转换后，应该调解为C041::foo()才对，做这种调解过于巨大，所以编译器爽性new了一个新的 C041的姑且工具出来。比拟这三行的最后二列即知。我不知道这是否是C++尺度类型中界说的行为，改天查到我再更新上来。
在new出新工具的同时，编译器还将原工具中属于父类部门的数据成员的值拷贝了过来。留意代码的第1行，c082.C041::c_ = 0x05;，我们先把c082工具中从C041类担任过来的数据成员的值改写为0x05，本来是的值是0x01，由C041的结构函数初始化。我们调查输出的第2行，上面说了这个被打印的工具并非c082而是编译器new出的来的姑且工具，可以留意到工具的最后一字节为0x05，即数据成员的值。所以我们知道编译器除了new出新的姑且工具外，还把原工具中相应的数据成员的值也复制了过来。
这和我以前的认识有点毛病，直观上我一直觉得这种转换不会发生新的工具，不外仔细想想编译器的这种作法也是对的，假如不发生新的工具，就意味着它要象前述的那样动态的改变虚表中条目标值。但new出姑且工具，也意味着利用下列的语句挪用，大概发生意想不到的功效。
((C041)c082).somefun();
假如somefun函数会改变工具的状态，那么上边的代码执行后，c082的状态并不会被改变。因为somefun实际改变的是姑且工具，在执行完后该姑且工具就扔掉了。这和直观的认识有所差别，一般会认为这个挪用会浸染于c082工具上。为了验证我们声明以下两个类。
struct C010
{
C010() : c_(0x01) {}
void foo() { c_ = 0x02; }
char c_;
};
struct C013 : public C010
{
C013() : c1_(0x01) {}
void foo() { c1_ = 0x02; }
char c1_;
};
两个类为担任干系，各有一个同名的普通成员函数，该函数改写类的相应成员变量。我们做以下的挪用：
C013 obj;
obj.foo();
((C010)obj).foo();
#p#分页标题#e#
第1个foo挪用，改变的是c1_值，最后一行的挪用改变的是c_的值。直观上容易认为上述代码执行后obj.c_和obj.c1_的值均为0x02。但我们在调试情况的局部变量窗口中把obj工具展开可以发明obj.c1_为0x02，但obj.c_为0x01。原因就是前面所说的((C010) obj)实际发生了一个姑且工具，所以最后一行的挪用没有浸染到obj工具上。
更进一步的想想，假如我们在一个类上运用了单件 (singleton)模式，而这个类又有一个担任布局，当在措施中想操作对工具举办向上转型来挪用父类的要领时，应该会呈现编译时错误，因为父类姑且工具无法结构。在这里有个前提，父类的结构函数应该用protected举办掩护，而不是用private，不然子类基础无法结构。这种我没有验证了，因为用这种要领挪用实在是较量蠢的作法，但不解除这种大概性。向上例中最后一行正确的挪用要领应该是：
obj.C010::foo();
这样就可以挪用到父类中被包围的函数，并且也是浸染在正确的工具上。
