随笔 - 9, 文章 - 0, 评论 - 0, 引用 - 0
数据加载中……

2018年7月31日

被控制的心理

我有些时候感觉心理不像是自己的,当其他人想起我时,情绪就会不可控的,非常让厌烦的,强烈的激动起来。
从科学的角度来说,这是一种无法理解的状态,但是它却发生了,无奈,又可悲。
一些无关紧要的人,却能强烈的影响我的情绪,真的是很可悲,而我又无可奈何,又痛苦难当,难道我要找千里之外一个不认识的、毫不相干的人去打一架,或者让他不要关注我,我能怎么做,很苦恼。
被控制的情绪,被任何关注我的人影响的心理,真的是很痛恨这种状态,要是有一天能摆脱掉,我的心就安宁了,比让我中百万彩票都更好。
被讨厌我的人影响情绪,被瞧不起我的人影响情绪,被敌视我的人影响情绪,世界能给我多留那么一点点空间吗。

posted @ 2018-07-31 16:14 niomaa 阅读(6) | 评论 (0)编辑 收藏

2016年1月15日

三角形切线推导

void calcTangent(VECTOR3D& p0,VECTOR3D& p1,VECTOR3D& p2, VECTOR2D& t0,VECTOR2D& t1,VECTOR2D& t2, VECTOR3D& tangent) { VECTOR3D edge1 = p1 - p0; VECTOR3D edge2 = p2 - p0; float du1 = t1.x - t0.x; float du2 = t2.x - t0.x; float dv1 = t1.y - t0.y; float dv2 = t2.y - t0.y; float f = 1.0f / (du1 * dv2 - du2 * dv1); tangent.x = f * (dv2 * edge1.x - dv1 * edge2.x); tangent.y = f * (dv2 * edge1.y - dv1 * edge2.y); tangent.z = f * (dv2 * edge1.z - dv1 * edge2.z); tangent.Normalize(); }

posted @ 2016-01-15 11:22 niomaa 阅读(49) | 评论 (0)编辑 收藏

2015年9月5日

阴影图(shadowmap)实现细节(2)

第一遍渲染在(1)里面已经详细描述了,需要注意的是,第一遍渲染把需要投射阴影的物体渲染一遍,这时不能有任何其他渲染来干扰rendertarget的写入;
一旦第一遍渲染结束后,将rendertarget中生成好的阴影图保存下来,留给第二遍渲染计算使用,并把旧的rendertargt与device绑定;
完成这些必要的步骤后,接下来就是第二遍渲染了
第二遍渲染:

posted @ 2015-09-05 09:50 niomaa 阅读(53) | 评论 (0)编辑 收藏

2015年9月1日

阴影图(shadowmap)实现细节(1)

     摘要: 阴影图实现细节和优化(1)  阅读全文

posted @ 2015-09-01 22:40 niomaa 阅读(1055) | 评论 (0)编辑 收藏

2015年5月19日

工作中遇到的一些问题小记


使用bdb用作数据存储时,路径不能设为中文,不然在bdb打开时时会失败

(在自己的电脑上是英文路径,在使用方电脑上是中文路径,坑爹的bug)





com的事件机制

IDispatch* pDispatch;



...



pDispatch->Invoke(dispId, IID_NULL, LOCALE_USER_DEFAULT, DISPATCH_METHOD, &disp, &varResult, NULL, NULL);

这个函数向控件本身推送事件消息



这几天终于把遗留大半年的问题搞清楚了, vs2005编译的东西一直在别人的电脑上跑步起来,exe执行不了,dll注册 不了。。。

原因是因为使用的osg库是debug版的!

以后再碰到这种问题,一定要保证所有引用的库都是release版本的,出现这种问题一般来说就是这种原因了,

另外可能会是缺少某些关联的dll所致,这时候需要用depends来查看关联dll并拷贝过去





模块计算机类型“x64”与目标计算机类型“X86”冲突

目前碰到这个问题的原因是因为链接器命令行里面使用 /machine:x64,而解决方案平台选的是win32平台产生的冲突,一般来说删掉 /machine:x64就没问题了



使用D3DXCreateEffectFromFile读取shader文件时经常会出现读取失败的情况,这个时候就需要分析错误原因出在什么地方,这个函数提供了一个LPD3DXBUFFER * ppCompilationErrors 作为返回错误信息的参数

LPD3DXBUFFER v_error = NULL;

hr = D3DXCreateEffectFromFile( pd3dDevice, str , NULL, NULL, dwShaderFlags, NULL, &m_d3dx_effect, &v_error );

const char *str_error = (char *)v_error->GetBufferPointer();

来获取错误信息

posted @ 2015-05-19 16:30 niomaa 阅读(97) | 评论 (0)编辑 收藏

2012年7月31日

C++宏的使用

C/C++宏的使用
 
1.防止多重包含2
 
2.条件编译2
 
3.定义字面值常量2
 
4.定义为函数2
 
5.可变参数宏3
 
6.宏组合3
 
6.1一般用法4
 
6.2当宏参数是另一个宏的时候4
 
6.2.1非'#'和'##'的情况4
 
6.2.2当有'#'或'##'的时候4
 
6.3'#'和'##'的一些应用特例5
 
6.3.1合并匿名变量名5
 
6.3.2填充结构5
 
6.3.3记录文件名6
 
6.3.4得到一个数值类型所对应的字符串缓冲大小6
 
7.其他使用例子6
 
7.1得到指定地址上的一个字节或字6
 
7.2求最大值和最小值6
 
7.3得到一个field在结构体(struct)中的偏移量6
 
7.4得到一个结构体中field所占用的字节数7
 
7.5按照LSB格式把两个字节转化为一个Word7
 
7.6按照LSB格式把一个Word转化为两个字节7
 
7.7得到一个变量的地址(word宽度)7
 
7.8得到一个字的高位和低位字节7
 
7.9返回一个比X大的最接近的8的倍数7
 
7.10将一个字母转换为大写7
 
7.11判断字符是不是10进值的数字7
 
7.12判断字符是不是16进值的数字8
 
7.13防止溢出的一个方法8
 
7.14返回数组元素的个数8
 
7.15对于IO空间映射在存储空间的结构,输入输出处理
 

1.防止多重包含
 
防止头文件多重包含:
 
如下
 
CODE:
 
#ifndef MAIN_H_
 
#define MAIN_H_
 
其它内容
 
#endif
 
作用就是阻止这个头文件被多次include。多次include就会出现重复的定义情况,所以需要在每个头文件中都使用这个定义。
 
2.条件编译
 
#ifdef _DEBUG
 
printf("this debug info/n");
 
#endif
 
如果没有定义_DEBUG宏,那么上面那一行是不会编译进去。但是定义了_DEBUG后,上面那行就会编译进去。
 
#ifdef _M_IX86
 
#elif defined _M_MRX000
 
#endif
 
3.定义字面值常量
 
方便修改,尽量做到修改地方少。
 
#define PRINT_STR "你好"
 
main()
 
{
 
printf(PRINT_STR);
 
return 0;
 
}
 
4.定义为函数
 
#ifdef _DEBUG
 
#define A(x) a(x)
 
#else
 
#define A(x) b(x)
 
#endif
 
int a(int x)
 
{
 
return x+1;
 
}
 
int b(int x)
 
{
 
return x+100;
 
}
 
int main()
 
{
 
printf ("A(10) value is %d",A(10));
 
return 0;
 
}
 
其实也可以定义成#define A a
 
但是定义成A(x)后只有A后面带一个(x)类型的编译器才会执行替换,比较安全,可以保证只替换函数而不替换变量。
 
5.可变参数宏
 
有些时候定义一个宏来代替某个函数,但是这个函数是可变参数的话,那就需要考虑办法了
 
定义方法如下
 
#include <iostream>
 
using namespace std;
 

#define PRINT(...) cout<<(__VA_ARGS__)
 
#define PRINTC(...) printf(__VA_ARGS__)
 


int _tmain(int argc, _TCHAR* argv[])
 
{
 
//C++6.0不可运行
 
PRINT("FLY编译例子");
 
PRINT(endl);
 
PRINTC("%d %s %s",1,"吃饭了吗 smile MM:)","/n");
 
return 0;
 
}
 
6.宏组合
 
也就是##和#的用法
 
##是连接符号,连接两个宏
 
#是把名字代替成字符串
 
6.1一般用法
 
#define s5(a) supper_##a
 
#include <stdio.h>
 
void supper_printf(const char* p )
 
{
 
printf("this is supper printf:/n%s/n",p);
 
}
 
int main()
 
{
 
s5(printf)("hello owrld");
 
return 0;
 
}
 
#用法如下
 
#include <stdio.h>
 
#define s(p) #p
 
int main()
 
{
 
printf(s(p)"/n");
 
return 0;
 
}
 
6.2当宏参数是另一个宏的时候
 
需要注意的是凡宏定义里有用'#'或'##'的地方宏参数是不会再展开。
 
6.2.1非'#'和'##'的情况
 
#define TOW (2)
 
#define MUL(a,b) (a*b)
 
printf("%d*%d=%d/n", TOW, TOW, MUL(TOW,TOW));
 
这行的宏会被展开为:
 
printf("%d*%d=%d/n", (2), (2), ((2)*(2)));
 
MUL里的参数TOW会被展开为(2)。
 
6.2.2当有'#'或'##'的时候
 
#define A (2)
 
#define STR(s) #s
 
#define CONS(a,b) int(a##e##b)
 
printf("int max: %s/n", STR(INT_MAX)); // INT_MAX #include<climits>
 
这行会被展开为:
 
printf("int max: %s/n", "INT_MAX");
 
printf("%s/n", CONS(A, A)); // compile error
 
这一行则是:
 
printf("%s/n", int(AeA));
 
INT_MAX和A都不会再被展开,然而解决这个问题的方法很简单。加多一层中间转换宏。
 
加这层宏的用意是把所有宏的参数在这层里全部展开,那么在转换宏里的那一个宏(_STR)就能得到正确的宏参数。
 
#define A (2)
 
#define _STR(s) #s
 
#define STR(s) _STR(s) // 转换宏
 
#define _CONS(a,b) int(a##e##b)
 
#define CONS(a,b) _CONS(a,b) // 转换宏
 
printf("int max: %s/n", STR(INT_MAX)); // INT_MAX,int型的最大值,为一个变量#include<climits>
 
输出为: int max: 0x7fffffff
 
STR(INT_MAX)-->_STR(0x7fffffff) 然后再转换成字符串;
 
printf("%d/n", CONS(A, A));
 
输出为:200
 
CONS(A, A)-->_CONS((2), (2))-->int((2)e(2))
 
6.3'#'和'##'的一些应用特例
 
6.3.1合并匿名变量名
 
#define ___ANONYMOUS1(type, var, line) type var##line
 
#define __ANONYMOUS0(type, line) ___ANONYMOUS1(type, _anonymous, line)
 
#define ANONYMOUS(type) __ANONYMOUS0(type, __LINE__)
 
例:ANONYMOUS(static int); 即: static int _anonymous70; 70表示该行行号;
 
第一层:ANONYMOUS(static int); --> __ANONYMOUS0(static int, __LINE__);
 
第二层: --> ___ANONYMOUS1(static int, _anonymous, 70);
 
第三层: --> static int _anonymous70;
 
即每次只能解开当前层的宏,所以__LINE__在第二层才能被解开。
 
6.3.2填充结构
 
#define FILL(a) {a, #a}
 
enum IDD{OPEN, CLOSE};
 
typedef struct MSG
 
{
 
IDD id;
 
const char * msg;
 
}MSG;
 
MSG _msg[] = {FILL(OPEN), FILL(CLOSE)};
 
相当于:
 
MSG _msg[] = {{OPEN, "OPEN"}, {CLOSE, "CLOSE"}};
 
6.3.3记录文件名
 
#define _GET_FILE_NAME(f) #f
 
#define GET_FILE_NAME(f) _GET_FILE_NAME(f)
 
static char FILE_NAME[] = GET_FILE_NAME(__FILE__);
 
6.3.4得到一个数值类型所对应的字符串缓冲大小
 
#define _TYPE_BUF_SIZE(type) sizeof #type
 
#define TYPE_BUF_SIZE(type) _TYPE_BUF_SIZE(type)
 
char buf[TYPE_BUF_SIZE(INT_MAX)];
 
--> char buf[_TYPE_BUF_SIZE(0x7fffffff)];
 
--> char buf[sizeof "0x7fffffff"];
 
这里相当于:
 
char buf[11];
 
7.其他使用例子
 
7.1得到指定地址上的一个字节或字
 
#define MEM_B( x ) ( *( (byte *) (x) ) )
 
#define MEM_W( x ) ( *( (word *) (x) ) )
 
7.2求最大值和最小值
 
#define MAX( x, y ) ( ((x) > (y)) ? (x) : (y) )
 
#define MIN( x, y ) ( ((x) < (y)) ? (x) : (y) )
 
7.3得到一个field在结构体(struct)中的偏移量
 
#define FPOS( type, field ) /
 
( (dword) &(( type *) 0)-> field )
 
7.4得到一个结构体中field所占用的字节数
 
#define FSIZ( type, field ) sizeof( ((type *) 0)->field )
 
7.5按照LSB格式把两个字节转化为一个Word
 
#define FLIPW( ray ) ( (((word) (ray)[0]) * 256) + (ray)[1] )
 
7.6按照LSB格式把一个Word转化为两个字节
 
#define FLOPW( ray, val ) /
 
(ray)[0] = ((val) / 256); /
 
(ray)[1] = ((val) & 0xFF)
 
7.7得到一个变量的地址(word宽度)
 
#define B_PTR( var ) ( (byte *) (void *) &(var) )
 
#define W_PTR( var ) ( (word *) (void *) &(var) )
 
7.8得到一个字的高位和低位字节
 
#define WORD_LO(xxx) ((byte) ((word)(xxx) & 255))
 
#define WORD_HI(xxx) ((byte) ((word)(xxx) >> 8))
 
7.9返回一个比X大的最接近的8的倍数
 
#define RND8( x ) ((((x) + 7) / 8 ) * 8 )
 
7.10将一个字母转换为大写
 
#define UPCASE( c ) ( ((c) >= ''a'' && (c) <= ''z'') ? ((c) - 0x20) : (c) )
 
7.11判断字符是不是10进值的数字
 
#define DECCHK( c ) ((c) >= ''0'' && (c) <= ''9'')
 
7.12判断字符是不是16进值的数字
 
#define HEXCHK( c ) ( ((c) >= ''0'' && (c) <= ''9'') ||/
 
((c) >= ''A'' && (c) <= ''F'') ||/
 
((c) >= ''a'' && (c) <= ''f'') )
 
7.13防止溢出的一个方法
 
#define INC_SAT( val ) (val = ((val)+1 > (val)) ? (val)+1 : (val))
 
7.14返回数组元素的个数
 
#define ARR_SIZE( a ) ( sizeof( (a) ) / sizeof( (a[0]) ) )
 
7.15对于IO空间映射在存储空间的结构,输入输出处理
 
#define inp(port) (*((volatile byte *) (port)))
 
#define inpw(port) (*((volatile word *) (port)))
 
#define inpdw(port) (*((volatile dword *)(port)))
 
#define outp(port, val) (*((volatile byte *) (port)) = ((byte) (val)))
 
#define outpw(port, val) (*((volatile word *) (port)) = ((word) (val)))
 
#define outpdw(port, val) (*((volatile dword *) (port)) = ((dword) (val)))

posted @ 2012-07-31 23:46 niomaa 阅读(138) | 评论 (0)编辑 收藏

2012年1月31日

转:投影矩阵的推导

转载链接:http://hi.baidu.com/twjblog/blog/item/ebe924cbcbf6fb28f9dc617b.html

本文乃<投影矩阵的推导>译文,原文地址为http://www.codeguru.com/cpp/misc/misc/math/article.php/c10123__1/Deriving-Projection-Matrices.htm,由于本人能力有限,有译的不明白的地方大家可以参考原文,谢谢^-^!

译者: 流星上的潴

如需转载,请注明出处,感谢!

 

在3D图形程序的基本矩阵变换中,投影矩阵是其中比较复杂的。平移和缩放浏览一下就能理解,旋转矩阵只要掌握了三角函数知识也可以理解,但投影矩阵有点棘手。如果你曾经看过投影矩阵,你会发现你的常识不足以告诉你它是怎么来的。而且,我在网上还未看到许多关于如何推导投影矩阵的教程资源。本文的话题就是如何推导投影矩阵。

对于刚刚开始接触3D图形的人,我应该指出,理解投影矩阵如何推导可能是我们对于数学的好奇心,它不是必须的。你可以只用公式,并且如果你用像Direct3D那样的图形API,你甚至都不需要使用公式,图形API会为你构建一个投影矩阵。所以,如果本文看起来有点难,不要害怕。只要你理解了投影矩阵做了什么,你没必要在你不想的情况下关注它是怎么做的。本文是给那些想了解更多的程序员的。

 

概述: 什么是投影?

计算机显示器是一个二维表面,所以如果你想显示三维图像,你需要一种方法把3D几何体转换成一种可作为二维图像渲染的形式。那也正是投影做的。拿一个简单的例子来说,一种把3D对象投影到2D表面的方法是简单的把每个坐标点的z坐标丢弃。对立方体来说,看上去可能像图1

                图1: 通过丢弃Z坐标投影到XY平面

当然,这过于简单,并且在大多数情况下不是特别有用。首先,根本不会投影到一个平面上;相反,投影公式将变换你的几何体到一个新的空间体中,称为规范视域体(canonical view volume),规范视域体的精确坐标可能在不同的图形API之间互不相同,但作为讨论起见,把它认为是从(-1, -1, 0)延伸至(1, 1, 1)的盒子,这也是Direct3D中使用的。一旦所有顶点被映射到规范视域体,只有它们的x和y坐标被用于映射到屏幕上。这并不代表z坐标是无用的,它通常被深度缓冲用于可见度测试。这就是为什么变换到一个新的空间体中,而不是投影到一个平面上。

注意,图1描述的是左手坐标系,摄像机俯视z轴正方向,y轴朝上并且x轴朝右。这是Direct3D中使用的坐标系,本文中我都将使用该坐标系。对于右手坐标系系统来说,在计算方面没有明显差异,在规范视域体方面有一点区别,所以一切讨论仍将适用即使你的图形API使用与Direct3D不同的规定。

现在,可以进入实际的投影变换了。有许多投影方法,我将介绍最常见的2种:正交和透视。

 

正交投影

正交投影,之所以这么称呼是因为所有的投影线都与最终的绘图表面垂直,是一种相对简单的投影技术。视域体---也就是包含所有你想显示的几何体的可视空间---是一个将被变换到规范视域体的轴对齐盒子,见图2

                                  图2: 正交投影

正如你看见的,视域体由6个面定义:

因为视域体和规范视域体都是轴对齐盒子,这种类型的投影没有距离更正。最终的结果是,事实上,很像图1那样每个坐标点只是丢弃了z坐标。对象在3D空间中的大小和在投影中的大小相同,即使一个对象比另一个对象距离摄像机远很多。在3D空间中平行的直线在最终的图像上也是平行的。使用这种类型的投影将出现一些问题像第一人称射击游戏---试想一下在不知道任何东西有多远的情况下玩!---但它也有它的用处。你可能在格子游戏中使用它,例如,特别是摄像机被绑定在一个固定角度的一款格子游戏中,图3显示了1个简单的例子

                    图3: 正交投影的一个简单例子

所以,事不宜迟,现在开始弄清楚它是如何工作的。最简单的方法可能是3个坐标轴分开考虑,并且计算如何沿着每个坐标轴将点从视域体映射到规范视域体。从x轴开始。视域体中的点的x坐标范围在[l, r],想把它变换到范围在[-1, 1]

现在,准备把范围缩小到我们期望的,各项减去l,这样,最左边的项变为0。另一种可能考虑的做法是平移范围使其以0为中心,而不是一端为0,但现在这种方式代数式更整洁,所以为了可读性起见我将以现在这种方式做

现在,范围的一端是0,你可以缩小到期望的大小。你期望x值的范围是2个单位宽,从1到-1,所以把各项乘以2/(r-l)。注意r-l是视域体的宽度,因此始终是一个正数,所以不用担心不等号会改变方向。

下一步,各项减去1就产生了我们期望的范围[-1, 1]

基本代数允许我们将中间项写成一个单一的分数

最后,把中间项分成2部分使它形如px+q的形式,我们需要把项组织成这种形式这样我们推导的公式就可以简单的转换成矩阵形式。

这个不等式的中间项告诉了我们把x转换到规范视域体的公式

获取y的变换公式的步骤是完全一样的---只要用y替代x,用t替代r,用b替代l---所以这里不重复它们了,只是给出结果

最后,需要推倒z的变换公式。z的推导有点点不同,因为需要把z映射到范围[0, 1]而不是[-1, 1],但看上去很相似。z坐标最开始在范围[n, f]

把各项减去n,这样的话范围的下限就变为了0

现在剩余要做的就是除以f-n,这样就产生了最终的范围[0, 1]。和前面相同,注意f-n是视域体的深度所以绝对不会为负

最后,把它分成2部分使它形如px+q的形式

这样便给出了z的变换公式

现在,可以准备写正交投影矩阵了。总结到目前为止的工作,推导了3个投影公式

如果写成矩阵形式,就得到了

就是这样!Direct3D提供了D3DXMatrixOrthoOffCenterLH()(what a mouthful!)方法构造一个和这个公式相同的正交投影矩阵;你可以在DirectX文档中找到。方法名中的"LH"代表了你正在使用左手坐标系。但是,究竟"OffCenter"的意思是什么呢?

这一问题的答案引导你到一个正交投影矩阵的简化形式。考虑几点: 首先,在可见空间中,摄像机定位在原点并且沿着z轴方向观看。第二,你通常希望你的视野在左右方向上延伸的同样远,并且在z轴的上下方向上也延伸的同样远。如果是这样的情况,那么z轴正好直接穿过你视域体的的中心,所以得到了r = -l并且t = -b。换句话说,你可以把r, l, t和b一起忘掉,简单的把视域体定义为1个宽度w和1个高度h,以及裁剪面f和n。如果你在正交投影矩阵中应用上面说的,那么你将得到这个相当简化的版本

这个公式是Direct3D中D3DXMatrixOrthoLH()方法的实现。你几乎可以一直使用这个矩阵替代上面那个你推导的更通用的"OffCenter"版本,除非你用投影做些奇怪的事情。

在完成这部分之前还有一点。它启发我们注意到这个矩阵可以用两个简单的变换串联替代: 平移其次是缩放。如果你思考几何的话这对你是有意义的,因为所有你在正交投影中做的就是从一个轴对齐盒子转向另一个轴对齐盒子;视域体不改变它的形状,只改变它的位置和大小。具体来说,有

这种投影方式可能更直观一点因为它让你更容易想象发生了什么。首先,视域体沿着z轴平移使它的近平面和原点重合;然后,应用一个缩放把它缩小到规范视域体大小。很容易理解吧,对不对?一个偏离中心(OffCenter)的正交投影矩阵也可以用一个变换和一个缩放代替,它和上面的结果很相似所以我在这里不列出了。

上面就是正交投影,现在可以去接触一些更有挑战性的东西了。

 

透视投影

透视投影是稍复杂的一种投影方法,并且用的越来越平凡,因为它创造了距离感,因此会生成更逼真的图像。从几何上说,这种方法与正交投影不同的地方在于透视投影的视域体是一个平截头体---也就是,一个截断的金字塔---而不是一个轴对称盒子。见图4

                                       图4: 透视投影

正如你所看见的,视域体的近平面从从(l, b, n)延伸至(r, t, n)。远平面范围是从原点发射穿过近平面四个点的射线直至与平面z=f相交。由于视域体从原点进一步延伸,它变得越来越宽大;同时你将这个形状变换到规范视域体盒子;视域体的远端比视域体的近端压缩的更厉害。因此,视域体远端的物体会变得更小,这就给了你距离感。

由于空间体形状的这种变换,透视投影不能像正交投影那样简单的表达为一个平移和一个缩放。你必须制定一些不同的东西。但是,这并不意味着你在正交投影上做的工作是无用的。一个方便的解决数学问题的方法是把问题减少到你已经知道怎么解决的那一个。所以,这就是你在这里可以做的。上一次,你一次检查一个坐标,但这次,你将把x和y坐标合起来一起做,然后再考虑z坐标。你对x和y的处理可以分2个步骤:

第1步: 给定视域体中的点(x, y, z),把它投影到近平面z=n。由于投影点在近平面上,所以它的x坐标范围在[l, r],y坐标范围在[b, t]。

第2步: 使用你在正交投影中学会推导的公式,把x坐标从[l, r]映射到[-1, 1],把y坐标范围从[b, t]映射到[-1, 1]。

听上去很棒吧?看一看图5

     图5: 使用相似三角形投影一个点到z=n平面

在这个图中,你从点(x, y, z)到原点画了条直线,注意直线与z=n平面相交的那个点---用黑色标记的那个。通过这些点,你画了2条相对于z轴的垂线,突然你得到了一对相似三角形。如果你能够回想起高中的几何知识,相似三角形是拥有相同形状但大小不一定相同的三角形。为了证明2个三角形是相似的,必须证明它们的同位角相等,在这里不难做到。角1被2个三角形共享,显然它和自身相等。角2和角3是穿越2条平行线形成的同位角,所以它们是相等的。同时,直角当然是彼此相等的,所以2个三角形是相似的。

对于相似三角形你应该感兴趣的是它们的每对对应边都是同比例的。你知道沿着z轴的边的长度,它们是n和z。那意味着其他对应边的比例也是n/z。所以,考虑下你知道了什么。根据勾股定理,从(x, y, z)相对于z轴做的垂线具有以下长度:

如果你知道了从你的投影点到z轴的垂线的长度,那么你就可以计算出该点的x和y坐标。长度怎么求?那太简单了!因为你有了相似三角形,所以长度就是简单的L乘以n/z:

 因此,x坐标是x * n/z,y坐标是y * n/z。第一步做完了。

第二步只是简单的执行你上一部分做的同样的映射,所以是时候回顾下你在正交投影中学习到的推导公式了。回想下把x和y坐标映射到规范视域体,像这样:

现在你可以再次调用这些公式,除非你要考虑到投影;所以,把x用x * n/z代替,把y用y * n/z代替:

现在,通过乘以z:

这些结果有点奇怪。为了把这些等式写进矩阵,你需要把它们写成这种形式:

但很明显,现在还做不到,所以现在看起来进入了僵局。应该做什么呢?如果你能找到个办法获得z'z的公式就像x'z和y'z那样,你就可以写一个变换矩阵把(x, y, z)映射到(x'z, y'z, z'z)。然后,你只需要把各部分除以点z,你就会得到你想要的(x', y', z')。

因为你知道z到z'的转换不依赖于x和y,你知道你想要一个公式形如z'z = pz + q,p和q是常量。并且,你可以很容易的找到那些常量,因为你知道在2种特殊情况下如何得到z': 因为你要把[n, f]映射到[0, 1],你知道当z=n时z'=0,和z=f时z'=1。当你把第一组值代入z'z = pz + q,你可以解得:

现在,把第二组值代入,得到:

把q的值代入等式,你可以很容易的解得p:

现在你有p的值了,并且刚刚你求得了q = –pn,所以你可以解得q:

最后,把p和q的表达式代入最原始的公式中,得:

你就快完成了,但是你处理这个问题的不寻常的性质需要你也处理齐次坐标w。通常情况下,只是简单的设置w' = 1---你可能已经注意到在一个基本的变换下最后一行总是[0, 0, 0, 1]---但是现在你在为点(x'z, y'z, z'z, w'z)写一个变换。所以取而代之的,把w' = 1写成w'z = z。因此最后用于透视投影的等式如下:

现在,当你把这个等式写成矩阵的形式,得到:

当你把这个矩阵用于点(x, y, z, 1),它将产生(x'z, y'z, z'z, w'z)。然后,你应用通常的步骤去除以齐次坐标,得到(x', y', z', 1)。那就是透视投影。Direct3D的D3DXMatrixPerspectiveOffCenterLH()方法也实现了上述公式。正如正交投影,如果你假设视域体是对称的并且中心是z轴(也就是r = -l,t = -b),你可以简单的用视域体的宽w和高h改写矩阵中的各项:

Direct3D的D3DXMatrixPerspectiveLH()方法也生成这个矩阵。

最后,还有个经常用的上的透视投影的表示。在这种表示中,你根据摄像机的可视范围定义视域体,而不用去担心视域体的尺寸。此概念参阅图6

图6: 视域体的高由垂直可视范围的角度a定义

垂直可视范围的角度是a。这个角度被z轴一分为二,所以根据基本的三角函数,你可以写下面的方程,关联a和近平面n以及屏幕高度h:

这个表达式可以取代投影矩阵中的高度。此外,使用横从比r代替宽度,r定义为显示区域的宽比高的横纵比。所以,得到:

因此,有了用垂直可视范围角度a和横纵比r构成的透视投影矩阵:

在Direct3D中,你可以使用D3DXMatrixPerspectiveFovLH()方法得到这种形式的矩阵。这种形式特别有用,因为你可以直接把r设置成渲染窗口的横纵比,并且可视范围角度为p / 4比较好。所以,你真正需要担心的事情只是定义视域体沿着z轴的范围。

 

总结

这就是所有的你需要的投影变换背后的数学概念。还有一些其他的不太常用的投影方法,并且如果你使用右手坐标系或者一个不同的规范视域体就会和我们讨论的有点不同,但是以本文的结论作为基础你应该很容易能够推导出那些公式。如果你想知道更多的关于投影或者其他变换的信息,看一看Tomas Moller和Eric Haines的Real-Time Rendering,或者James D. Foley, Andries van Dam, Steven K. Feiner和John F. HughesComputer Graphics: Principles and Practice;这2本是优秀的关于计算机图形的书。

如果你对本文有任何问题,或者需要指出任何需要更正的地方,你可以通过CodeGuru论坛联系我,我的名字是Smasher/Devourer。

Happy coding!

 

END     流星上的潴       译



posted @ 2012-01-31 09:13 niomaa 阅读(1502) | 评论 (0)编辑 收藏

2012年1月29日

转: 使用__FILE__和__LINE__定位错误

posted @ 2012-01-29 15:00 niomaa 阅读(146) | 评论 (0)编辑 收藏

转: VC++,掀起你的盖头来 .

转载链接:http://blog.csdn.net/rainlight/article/details/614792

VC++,掀起你的盖头来
——谈VC++对象模型
(美)简  格雷
程化    译

译者前言

一个C++程序员,想要进一步提升技术水平的话,应该多了解一些语言的语意细节。对于使用VC++的程序员来说,还应该了解一些VC++对于C++的诠释。Inside the C++ Object Model虽然是一本好书,然而,书的篇幅多一些,又和具体的VC++关系小一些。因此,从篇幅和内容来看,译者认为本文是深入理解C++对象模型比较好的一个出发点。
这篇文章以前看到时就觉得很好,旧文重读,感觉理解得更多一些了,于是产生了翻译出来,与大家共享的想法。虽然文章不长,但时间有限,又若干次在翻译时打盹睡着,拖拖拉拉用了小一个月。
一方面因本人水平所限,另一方面因翻译时经常打盹,错误之处恐怕不少,欢迎大家批评指正。

1 前言

了解你所使用的编程语言究竟是如何实现的,对于C++程序员可能特别有意义。首先,它可以去除我们对于所使用语言的神秘感,使我们不至于对于编译器干的活感到完全不可思议;尤其重要的是,它使我们在Debug和使用语言高级特性的时候,有更多的把握。当需要提高代码效率的时候,这些知识也能够很好地帮助我们。

本文着重回答这样一些问题:
 * 类如何布局?
 * 成员变量如何访问?
 * 成员函数如何访问?
 * 所谓的“调整块”(adjuster thunk)是怎么回事?
 * 使用如下机制时,开销如何:
 * 单继承、多重继承、虚继承
 * 虚函数调用
 * 强制转换到基类,或者强制转换到虚基类
 * 异常处理
首先,我们顺次考察C兼容的结构(struct)的布局,单继承,多重继承,以及虚继承;
接着,我们讲成员变量和成员函数的访问,当然,这里面包含虚函数的情况;
再接下来,我们考察构造函数,析构函数,以及特殊的赋值操作符成员函数是如何工作的,数组是如何动态构造和销毁的;
最后,简单地介绍对异常处理的支持。

对每个语言特性,我们将简要介绍该特性背后的动机,该特性自身的语意(当然,本文决不是“C++入门”,大家对此要有充分认识),以及该特性在微软的VC++中是如何实现的。这里要注意区分抽象的C++语言语意与其特定实现。微软之外的其他C++厂商可能提供一个完全不同的实现,我们偶尔也会将VC++的实现与其他实现进行比较。

2 类布局

本节讨论不同的继承方式造成的不同内存布局。

2.1 C结构(struct)

由于C++基于C,所以C++也“基本上”兼容C。特别地,C++规范在“结构”上使用了和C相同的,简单的内存布局原则:成员变量按其被声明的顺序排列,按具体实现所规定的对齐原则在内存地址上对齐。所有的C/C++厂商都保证他们的C/C++编译器对于有效的C结构采用完全相同的布局。这里,A是一个简单的C结构,其成员布局和对齐方式都一目了然。


struct A {
   char c;
   int i;
};

译者注:从上图可见,A在内存中占有8个字节,按照声明成员的顺序,前4个字节包含一个字符(实际占用1个字节,3个字节空着,补对齐),后4个字节包含一个整数。A的指针就指向字符开始字节处。

2.2 有C++特征的C结构


当然了,C++不是复杂的C,C++本质上是面向对象的语言:包含继承、封装,以及多态。原始的C结构经过改造,成了面向对象世界的基石——类。除了成员变量外,C++类还可以封装成员函数和其他东西。然而,有趣的是,除非为了实现虚函数和虚继承引入的隐藏成员变量外,C++类实例的大小完全取决于一个类及其基类的成员变量!成员函数基本上不影响类实例的大小。

这里提供的B是一个C结构,然而,该结构有一些C++特征:控制成员可见性的“public/protected/private”关键字、成员函数、静态成员,以及嵌套的类型声明。虽然看着琳琅满目,实际上只有成员变量才占用类实例的空间。要注意的是,C++标准委员会不限制由“public/protected/private”关键字分开的各段在实现时的先后顺序,因此,不同的编译器实现的内存布局可能并不相同。(在VC++中,成员变量总是按照声明时的顺序排列)。

struct B {
public:
   int bm1;
protected:
   int bm2;
private:
   int bm3;
   static int bsm;
   void bf();
   static void bsf();
   typedef void* bpv;
   struct N { };
};

译者注:B中,为何static int bsm不占用内存空间?因为它是静态成员,该数据存放在程序的数据段中,不在类实例中。

2.3 单继承


C++提供继承的目的是在不同的类型之间提取共性。比如,科学家对物种进行分类,从而有种、属、纲等说法。有了这种层次结构,我们才可能将某些具备特定性质的东西归入到最合适的分类层次上,如“怀孩子的是哺乳动物”。由于这些属性可以被子类继承,所以,我们只要知道“鲸鱼、人”是哺乳动物,就可以方便地指出“鲸鱼、人都可以怀孩子”。那些特例,如鸭嘴兽(生蛋的哺乳动物),则要求我们对缺省的属性或行为进行覆盖。
C++中的继承语法很简单,在子类后加上“:base”就可以了。下面的D继承自基类C。

struct C {
   int c1;
   void cf();
};

struct D : C {
   int d1;
   void df();
};

既然派生类要保留基类的所有属性和行为,自然地,每个派生类的实例都包含了一份完整的基类实例数据。在D中,并不是说基类C的数据一定要放在D的数据之前,只不过这样放的话,能够保证D中的C对象地址,恰好是D对象地址的第一个字节。这种安排之下,有了派生类D的指针,要获得基类C的指针,就不必要计算偏移量了。几乎所有知名的C++厂商都采用这种内存安排。在单继承类层次下,每一个新的派生类都简单地把自己的成员变量添加到基类的成员变量之后。看看上图,C对象指针和D对象指针指向同一地址。

2.4 多重继承


大多数情况下,其实单继承就足够了。但是,C++为了我们的方便,还提供了多重继承。

比如,我们有一个组织模型,其中有经理类(分任务),工人类(干活)。那么,对于一线经理类,即既要从上级经理那里领取任务干活,又要向下级工人分任务的角色来说,如何在类层次中表达呢?单继承在此就有点力不胜任。我们可以安排经理类先继承工人类,一线经理类再继承经理类,但这种层次结构错误地让经理类继承了工人类的属性和行为。反之亦然。当然,一线经理类也可以仅仅从一个类(经理类或工人类)继承,或者一个都不继承,重新声明一个或两个接口,但这样的实现弊处太多:多态不可能了;未能重用现有的接口;最严重的是,当接口变化时,必须多处维护。最合理的情况似乎是一线经理从两个地方继承属性和行为——经理类、工人类。

C++就允许用多重继承来解决这样的问题:

struct Manager ... { ... };
struct Worker ... { ... };
struct MiddleManager : Manager, Worker { ... };

这样的继承将造成怎样的类布局呢?下面我们还是用“字母类”来举例:

struct E {
   int e1;
   void ef();
};

struct F : C, E {
   int f1;
   void ff();
 
 
};
 
结构F从C和E多重继承得来。与单继承相同的是,F实例拷贝了每个基类的所有数据。与单继承不同的是,在多重继承下,内嵌的两个基类的对象指针不可能全都与派生类对象指针相同:
 
F f;
// (void*)&f == (void*)(C*)&f;
// (void*)&f <  (void*)(E*)&f;
译者注:上面那行说明C对象指针与F对象指针相同,下面那行说明E对象指针与F对象指针不同。

观察类布局,可以看到F中内嵌的E对象,其指针与F指针并不相同。正如后文讨论强制转化和成员函数时指出的,这个偏移量会造成少量的调用开销。

具体的编译器实现可以自由地选择内嵌基类和派生类的布局。VC++按照基类的声明顺序先排列基类实例数据,最后才排列派生类数据。当然,派生类数据本身也是按照声明顺序布局的(本规则并非一成不变,我们会看到,当一些基类有虚函数而另一些基类没有时,内存布局并非如此)。

2.5 虚继承


回到我们讨论的一线经理类例子。让我们考虑这种情况:如果经理类和工人类都继承自“雇员类”,将会发生什么?
 
struct Employee { ... };
struct Manager : Employee { ... };
struct Worker : Employee { ... };
struct MiddleManager : Manager, Worker { ... };
 
如果经理类和工人类都继承自雇员类,很自然地,它们每个类都会从雇员类获得一份数据拷贝。如果不作特殊处理,一线经理类的实例将含有两个雇员类实例,它们分别来自两个雇员基类。如果雇员类成员变量不多,问题不严重;如果成员变量众多,则那份多余的拷贝将造成实例生成时的严重开销。更糟的是,这两份不同的雇员实例可能分别被修改,造成数据的不一致。因此,我们需要让经理类和工人类进行特殊的声明,说明它们愿意共享一份雇员基类实例数据。

很不幸,在C++中,这种“共享继承”被称为“虚继承”,把问题搞得似乎很抽象。虚继承的语法很简单,在指定基类时加上virtual关键字即可。
 
struct Employee { ... };
struct Manager : virtual Employee { ... };
struct Worker : virtual Employee { ... };
struct MiddleManager : Manager, Worker { ... };
 
使用虚继承,比起单继承和多重继承有更大的实现开销、调用开销。回忆一下,在单继承和多重继承的情况下,内嵌的基类实例地址比起派生类实例地址来,要么地址相同(单继承,以及多重继承的最靠左基类),要么地址相差一个固定偏移量(多重继承的非最靠左基类)。然而,当虚继承时,一般说来,派生类地址和其虚基类地址之间的偏移量是不固定的,因为如果这个派生类又被进一步继承的话,最终派生类会把共享的虚基类实例数据放到一个与上一层派生类不同的偏移量处。请看下例:
 
struct G : virtual C {
   int g1;
   void gf();
};
 
译者注:GdGvbptrG(In G, the displacement of G’s virtual base pointer to G)意思是:在G中,G对象的指针与G的虚基类表指针之间的偏移量,在此可见为0,因为G对象内存布局第一项就是虚基类表指针; GdGvbptrC(In G, the displacement of G’s virtual base pointer to C)意思是:在G中,C对象的指针与G的虚基类表指针之间的偏移量,在此可见为4。

struct H : virtual C {
   int h1;
   void hf();
};
 
struct I : G, H {
   int i1;
   void _if();
};
 
暂时不追究vbptr成员变量从何而来。从上面这些图可以直观地看到,在G对象中,内嵌的C基类对象的数据紧跟在G的数据之后,在H对象中,内嵌的C基类对象的数据也紧跟在H的数据之后。但是,在I对象中,内存布局就并非如此了。VC++实现的内存布局中,G对象实例中G对象和C对象之间的偏移,不同于I对象实例中G对象和C对象之间的偏移。当使用指针访问虚基类成员变量时,由于指针可以是指向派生类实例的基类指针,所以,编译器不能根据声明的指针类型计算偏移,而必须找到另一种间接的方法,从派生类指针计算虚基类的位置。

在VC++中,对每个继承自虚基类的类实例,将增加一个隐藏的“虚基类表指针”(vbptr)成员变量,从而达到间接计算虚基类位置的目的。该变量指向一个全类共享的偏移量表,表中项目记录了对于该类而言,“虚基类表指针”与虚基类之间的偏移量。

其它的实现方式中,有一种是在派生类中使用指针成员变量。这些指针成员变量指向派生类的虚基类,每个虚基类一个指针。这种方式的优点是:获取虚基类地址时,所用代码比较少。然而,编译器优化代码时通常都可以采取措施避免重复计算虚基类地址。况且,这种实现方式还有一个大弊端:从多个虚基类派生时,类实例将占用更多的内存空间;获取虚基类的虚基类的地址时,需要多次使用指针,从而效率较低等等。

在VC++中,G拥有一个隐藏的“虚基类表指针”成员,指向一个虚基类表,该表的第二项是GdGvbptrC。(在G中,虚基类对象C的地址与G的“虚基类表指针”之间的偏移量(当对于所有的派生类来说偏移量不变时,省略“d”前的前缀))。比如,在32位平台上,GdGvptrC是8个字节。同样,在I实例中的G对象实例也有“虚基类表指针”,不过该指针指向一个适用于“G处于I之中”的虚基类表,表中一项为IdGvbptrC,值为20。

观察前面的G、H和I,我们可以得到如下关于VC++虚继承下内存布局的结论:
 首先排列非虚继承的基类实例;
 有虚基类时,为每个基类增加一个隐藏的vbptr,除非已经从非虚继承的类那里继承了一个vbptr;
 排列派生类的新数据成员;
 在实例最后,排列每个虚基类的一个实例。

该布局安排使得虚基类的位置随着派生类的不同而“浮动不定”,但是,非虚基类因此也就凑在一起,彼此的偏移量固定不变。

3 成员变量

介绍了类布局之后,我们接着考虑对不同的继承方式,访问成员变量的开销究竟如何。

没有继承。没有任何继承关系时,访问成员变量和C语言的情况完全一样:从指向对象的指针,考虑一定的偏移量即可。
 
C* pc;
pc->c1; // *(pc + dCc1);
译者注:pc是指向C的指针。
 访问C的成员变量c1,只需要在pc上加上固定的偏移量dCc1(在C中,C指针地址与其c1成员变量之间的偏移量值),再获取该指针的内容即可。

单继承。由于派生类实例与其基类实例之间的偏移量是常数0,所以,可以直接利用基类指针和基类成员之间的偏移量关系,如此计算得以简化。
 
D* pd;
pd->c1; // *(pd + dDC + dCc1); // *(pd + dDc1);
pd->d1; // *(pd + dDd1);
译者注:D从C单继承,pd为指向D的指针。
 当访问基类成员c1时,计算步骤本来应该为“pd+dDC+dCc1”,即为先计算D对象和C对象之间的偏移,再在此基础上加上C对象指针与成员变量c1之间的偏移量。然而,由于dDC恒定为0,所以直接计算C对象地址与c1之间的偏移就可以了。
 当访问派生类成员d1时,直接计算偏移量。

多重继承。虽然派生类与某个基类之间的偏移量可能不为0,然而,该偏移量总是一个常数。只要是个常数,访问成员变量,计算成员变量偏移时的计算就可以被简化。可见即使对于多重继承来说,访问成员变量开销仍然不大。
 
F* pf;
pf->c1; // *(pf + dFC + dCc1); // *(pf + dFc1);
pf->e1; // *(pf + dFE + dEe1); // *(pf + dFe1);
pf->f1; // *(pf + dFf1);
译者注:F继承自C和E,pf是指向F对象的指针。
 访问C类成员c1时,F对象与内嵌C对象的相对偏移为0,可以直接计算F和c1的偏移;
 访问E类成员e1时,F对象与内嵌E对象的相对偏移是一个常数,F和e1之间的偏移计算也可以被简化;
 访问F自己的成员f1时,直接计算偏移量。

虚继承。当类有虚基类时,访问非虚基类的成员仍然是计算固定偏移量的问题。然而,访问虚基类的成员变量,开销就增大了,因为必须经过如下步骤才能获得成员变量的地址:获取“虚基类表指针”;获取虚基类表中某一表项的内容;把内容中指出的偏移量加到“虚基类表指针”的地址上。然而,事情并非永远如此。正如下面访问I对象的c1成员那样,如果不是通过指针访问,而是直接通过对象实例,则派生类的布局可以在编译期间静态获得,偏移量也可以在编译时计算,因此也就不必要根据虚基类表的表项来间接计算了。

I* pi;
pi->c1; // *(pi + dIGvbptr + (*(pi+dIGvbptr))[1] + dCc1);
pi->g1; // *(pi + dIG + dGg1); // *(pi + dIg1);
pi->h1; // *(pi + dIH + dHh1); // *(pi + dIh1);
pi->i1; // *(pi + dIi1);
I i;
i.c1; // *(&i + IdIC + dCc1); // *(&i + IdIc1);
译者注:I继承自G和H,G和H的虚基类是C,pi是指向I对象的指针。
 访问虚基类C的成员c1时,dIGvbptr是“在I中,I对象指针与G的“虚基类表指针”之间的偏移”,*(pi + dIGvbptr)是虚基类表的开始地址,*(pi + dIGvbptr)[1]是虚基类表的第二项的内容(在I对象中,G对象的“虚基类表指针”与虚基类之间的偏移),dCc1是C对象指针与成员变量c1之间的偏移;
 访问非虚基类G的成员g1时,直接计算偏移量;
 访问非虚基类H的成员h1时,直接计算偏移量;
 访问自身成员i1时,直接使用偏移量;
 当声明了一个对象实例,用点“.”操作符访问虚基类成员c1时,由于编译时就完全知道对象的布局情况,所以可以直接计算偏移量

当访问类继承层次中,多层虚基类的成员变量时,情况又如何呢?比如,访问虚基类的虚基类的成员变量时?一些实现方式为:保存一个指向直接虚基类的指针,然后就可以从直接虚基类找到它的虚基类,逐级上推。VC++优化了这个过程。VC++在虚基类表中增加了一些额外的项,这些项保存了从派生类到其各层虚基类的偏移量。

4 强制转化

如果没有虚基类的问题,将一个指针强制转化为另一个类型的指针代价并不高昂。如果在要求转化的两个指针之间有“基类-派生类”关系,编译器只需要简单地在两者之间加上或者减去一个偏移量即可(并且该量还往往为0)。

F* pf;
(C*)pf; // (C*)(pf ? pf + dFC : 0); // (C*)pf;
(E*)pf; // (E*)(pf ? pf + dFE : 0);

C和E是F的基类,将F的指针pf转化为C*或E*,只需要将pf加上一个相应的偏移量。转化为C类型指针C*时,不需要计算,因为F和C之间的偏移量为0。转化为E类型指针E*时,必须在指针上加一个非0的偏移常量dFE。C++规范要求NULL指针在强制转化后依然为NULL,因此在做强制转化需要的运算之前,VC++会检查指针是否为NULL。当然,这个检查只有当指针被显示或者隐式转化为相关类型指针时才进行;当在派生类对象中调用基类的方法,从而派生类指针被在后台转化为一个基类的Const “this” 指针时,这个检查就不需要进行了,因为在此时,该指针一定不为NULL。

正如你猜想的,当继承关系中存在虚基类时,强制转化的开销会比较大。具体说来,和访问虚基类成员变量的开销相当。

I* pi;
(G*)pi; // (G*)pi;
(H*)pi; // (H*)(pi ? pi + dIH : 0);
(C*)pi; // (C*)(pi ? (pi+dIGvbptr + (*(pi+dIGvbptr))[1]) : 0);
译者注:pi是指向I对象的指针,G,H是I的基类,C是G,H的虚基类。
 强制转化pi为G*时,由于G*和I*的地址相同,不需要计算;
 强制转化pi为H*时,只需要考虑一个常量偏移;
 强制转化pi为C*时,所作的计算和访问虚基类成员变量的开销相同,首先得到G的虚基类表指针,再从虚基类表的第二项中取出G到虚基类C的偏移量,最后根据pi、虚基类表偏移和虚基类C与虚基类表指针之间的偏移计算出C*。

一般说来,当从派生类中访问虚基类成员时,应该先强制转化派生类指针为虚基类指针,然后一直使用虚基类指针来访问虚基类成员变量。这样做,可以避免每次都要计算虚基类地址的开销。见下例。

/* before: */             ... pi->c1 ... pi->c1 ...
/* faster: */ C* pc = pi; ... pc->c1 ... pc->c1 ...
译者注:前者一直使用派生类指针pi,故每次访问c1都有计算虚基类地址的较大开销;后者先将pi转化为虚基类指针pc,故后续调用可以省去计算虚基类地址的开销。

5 成员函数

一个C++成员函数只是类范围内的又一个成员。X类每一个非静态的成员函数都会接受一个特殊的隐藏参数——this指针,类型为X* const。该指针在后台初始化为指向成员函数工作于其上的对象。同样,在成员函数体内,成员变量的访问是通过在后台计算与this指针的偏移来进行。
 
struct P {
   int p1;
   void pf(); // new
   virtual void pvf(); // new
 
 
};
 

P有一个非虚成员函数pf(),以及一个虚成员函数pvf()。很明显,虚成员函数造成对象实例占用更多内存空间,因为虚成员函数需要虚函数表指针。这一点以后还会谈到。这里要特别指出的是,声明非虚成员函数不会造成任何对象实例的内存开销。现在,考虑P::pf()的定义。
 
void P::pf() { // void P::pf([P *const this])
   ++p1;   // ++(this->p1);
}

这里P:pf()接受了一个隐藏的this指针参数,对于每个成员函数调用,编译器都会自动加上这个参数。同时,注意成员变量访问也许比看起来要代价高昂一些,因为成员变量访问通过this指针进行,在有的继承层次下,this指针需要调整,所以访问的开销可能会比较大。然而,从另一方面来说,编译器通常会把this指针缓存到寄存器中,所以,成员变量访问的代价不会比访问局部变量的效率更差。
译者注:访问局部变量,需要到SP寄存器中得到栈指针,再加上局部变量与栈顶的偏移。在没有虚基类的情况下,如果编译器把this指针缓存到了寄存器中,访问成员变量的过程将与访问局部变量的开销相似。

5.1 覆盖成员函数


和成员变量一样,成员函数也会被继承。与成员变量不同的是,通过在派生类中重新定义基类函数,一个派生类可以覆盖,或者说替换掉基类的函数定义。覆盖是静态(根据成员函数的静态类型在编译时决定)还是动态(通过对象指针在运行时动态决定),依赖于成员函数是否被声明为“虚函数”。

Q从P继承了成员变量和成员函数。Q声明了pf(),覆盖了P::pf()。Q还声明了pvf(),覆盖了P::pvf()虚函数。Q还声明了新的非虚成员函数qf(),以及新的虚成员函数qvf()。

struct Q : P {
   int q1;
   void pf();  // overrides P::pf
   void qf();  // new
   void pvf(); // overrides P::pvf
   virtual void qvf(); // new
};
 
对于非虚的成员函数来说,调用哪个成员函数是在编译时,根据“->”操作符左边指针表达式的类型静态决定的。特别地,即使ppq指向Q的实例,ppq->pf()仍然调用的是P::pf(),因为ppq被声明为“P*”。(注意,“->”操作符左边的指针类型决定隐藏的this参数的类型。)
 
P p; P* pp = &p; Q q; P* ppq = &q; Q* pq = &q;
pp->pf();  // pp->P::pf();  // P::pf(pp);
ppq->pf(); // ppq->P::pf(); // P::pf(ppq);
pq->pf();  // pq->Q::pf();  // Q::pf((P*)pq); (错误!)
pq->qf();  // pq->Q::qf();  // Q::qf(pq);
译者注:标记“错误”处,P*似应为Q*。因为pf非虚函数,而pq的类型为Q*,故应该调用到Q的pf函数上,从而该函数应该要求一个Q* const类型的this指针。

对于虚函数调用来说,调用哪个成员函数在运行时决定。不管“->”操作符左边的指针表达式的类型如何,调用的虚函数都是由指针实际指向的实例类型所决定。比如,尽管ppq的类型是P*,当ppq指向Q的实例时,调用的仍然是Q::pvf()。
 
pp->pvf();  // pp->P::pvf();  // P::pvf(pp);
ppq->pvf(); // ppq->Q::pvf(); // Q::pvf((Q*)ppq);
pq->pvf();  // pq->Q::pvf();  // Q::pvf((P*)pq); (错误!)
译者注:标记“错误”处,P*似应为Q*。因为pvf是虚函数,pq本来就是Q*,又指向Q的实例,从哪个方面来看都不应该是P*。

为了实现这种机制,引入了隐藏的vfptr成员变量。一个vfptr被加入到类中(如果类中没有的话),该vfptr指向类的虚函数表(vftable)。类中每个虚函数在该类的虚函数表中都占据一项。每项保存一个对于该类适用的虚函数的地址。因此,调用虚函数的过程如下:取得实例的vfptr;通过vfptr得到虚函数表的一项;通过虚函数表该项的函数地址间接调用虚函数。也就是说,在普通函数调用的参数传递、调用、返回指令开销外,虚函数调用还需要额外的开销。

回头再看看P和Q的内存布局,可以发现,VC++编译器把隐藏的vfptr成员变量放在P和Q实例的开始处。这就使虚函数的调用能够尽量快一些。实际上,VC++的实现方式是,保证任何有虚函数的类的第一项永远是vfptr。这就可能要求在实例布局时,在基类前插入新的vfptr,或者要求在多重继承时,虽然在右边,然而有vfptr的基类放到左边没有vfptr的基类的前面。

许多C++的实现会共享或者重用从基类继承来的vfptr。比如,Q并不会有一个额外的vfptr,指向一个专门存放新的虚函数qvf()的虚函数表。Qvf项只是简单地追加到P的虚函数表的末尾。如此一来,单继承的代价就不算高昂。一旦一个实例有vfptr了,它就不需要更多的vfptr。新的派生类可以引入更多的虚函数,这些新的虚函数只是简单地在已存在的,“每类一个”的虚函数表的末尾追加新项。

5.2 多重继承下的虚函数

如果从多个有虚函数的基类继承,一个实例就有可能包含多个vfptr。考虑如下的R和S类:
 
struct R {
   int r1;
   virtual void pvf(); // new
   virtual void rvf(); // new
};
 

struct S : P, R {
   int s1;
   void pvf(); // overrides P::pvf and R::pvf
   void rvf(); // overrides R::rvf
   void svf(); // new
};
 

这里R是另一个包含虚函数的类。因为S从P和R多重继承,S的实例内嵌P和R的实例,以及S自身的数据成员S::s1。注意,在多重继承下,靠右的基类R,其实例的地址和P与S不同。S::pvf覆盖了P::pvf()和R::pvf(),S::rvf()覆盖了R::rvf()。
 
S s; S* ps = &s;
((P*)ps)->pvf(); // (*(P*)ps)->P::vfptr[0])((S*)(P*)ps)
((R*)ps)->pvf(); // (*(R*)ps)->R::vfptr[0])((S*)(R*)ps)
ps->pvf();       // one of the above; calls S::pvf()
译者注:
 调用((P*)ps)->pvf()时,先到P的虚函数表中取出第一项,然后把ps转化为S*作为this指针传递进去;
 调用((R*)ps)->pvf()时,先到R的虚函数表中取出第一项,然后把ps转化为S*作为this指针传递进去;

因为S::pvf()覆盖了P::pvf()和R::pvf(),在S的虚函数表中,相应的项也应该被覆盖。然而,我们很快注意到,不光可以用P*,还可以用R*来调用pvf()。问题出现了:R的地址与P和S的地址不同。表达式(R*)ps与表达式(P*)ps指向类布局中不同的位置。因为函数S::pvf希望获得一个S*作为隐藏的this指针参数,虚函数必须把R*转化为S*。因此,在S对R虚函数表的拷贝中,pvf函数对应的项,指向的是一个“调整块”的地址,该调整块使用必要的计算,把R*转换为需要的S*。
译者注:这就是“thunk1: this-= sdPR; goto S::pvf”干的事。先根据P和R在S中的偏移,调整this为P*,也就是S*,然后跳转到相应的虚函数处执行。

在微软VC++实现中,对于有虚函数的多重继承,只有当派生类虚函数覆盖了多个基类的虚函数时,才使用调整块。

5.3 地址点与“逻辑this调整”

考虑下一个虚函数S::rvf(),该函数覆盖了R::rvf()。我们都知道S::rvf()必须有一个隐藏的S*类型的this参数。但是,因为也可以用R*来调用rvf(),也就是说,R的rvf虚函数槽可能以如下方式被用到:
 
((R*)ps)->rvf(); // (*((R*)ps)->R::vfptr[1])((R*)ps)
 
所以,大多数实现用另一个调整块将传递给rvf的R*转换为S*。还有一些实现在S的虚函数表末尾添加一个特别的虚函数项,该虚函数项提供方法,从而可以直接调用ps->rvf(),而不用先转换R*。MSC++的实现不是这样,MSC++有意将S::rvf编译为接受一个指向S中嵌套的R实例,而非指向S实例的指针(我们称这种行为是“给派生类的指针类型与该虚函数第一次被引入时接受的指针类型相同”)。所有这些在后台透明发生,对成员变量的存取,成员函数的this指针,都进行“逻辑this调整”。

当然,在debugger中,必须对这种this调整进行补偿。
 
ps->rvf(); // ((R*)ps)->rvf(); // S::rvf((R*)ps)
译者注:调用rvf虚函数时,直接给入R*作为this指针。

所以,当覆盖非最左边的基类的虚函数时,MSC++一般不创建调整块,也不增加额外的虚函数项。

5.4 调整块

正如已经描述的,有时需要调整块来调整this指针的值(this指针通常位于栈上返回地址之下,或者在寄存器中),在this指针上加或减去一个常量偏移,再调用虚函数。某些实现(尤其是基于cfront的)并不使用调整块机制。它们在每个虚函数表项中增加额外的偏移数据。每当虚函数被调用时,该偏移数据(通常为0),被加到对象的地址上,然后对象的地址再作为this指针传入。

ps->rvf();
// struct { void (*pfn)(void*); size_t disp; };
// (*ps->vfptr[i].pfn)(ps + ps->vfptr[i].disp);
译者注:当调用rvf虚函数时,前一句表示虚函数表每一项是一个结构,结构中包含偏移量;后一句表示调用第i个虚函数时,this指针使用保存在虚函数表中第i项的偏移量来进行调整。

这种方法的缺点是虚函数表增大了,虚函数的调用也更加复杂。

现代基于PC的实现一般采用“调整—跳转”技术:
 
S::pvf-adjust: // MSC++
this -= SdPR;
goto S::pvf()
 
当然,下面的代码序列更好(然而,当前没有任何实现采用该方法):
 
S::pvf-adjust:
this -= SdPR; // fall into S::pvf()
S::pvf() { ... }
译者注:IBM的C++编译器使用该方法。

5.5 虚继承下的虚函数

T虚继承P,覆盖P的虚成员函数,声明了新的虚函数。如果采用在基类虚函数表末尾添加新项的方式,则访问虚函数总要求访问虚基类。在VC++中,为了避免获取虚函数表时,转换到虚基类P的高昂代价,T中的新虚函数通过一个新的虚函数表获取,从而带来了一个新的虚函数表指针。该指针放在T实例的顶端。
 
struct T : virtual P {
   int t1;
   void pvf();         // overrides P::pvf
   virtual void tvf(); // new
};
 
void T::pvf() {
   ++p1; // ((P*)this)->p1++; // vbtable lookup!
   ++t1; // this->t1++;
}
 
如上所示,即使是在虚函数中,访问虚基类的成员变量也要通过获取虚基类表的偏移,实行计算来进行。这样做之所以必要,是因为虚函数可能被进一步继承的类所覆盖,而进一步继承的类的布局中,虚基类的位置变化了。下面就是这样的一个类:
 
struct U : T {
   int u1;
};
 

在此U增加了一个成员变量,从而改变了P的偏移。因为VC++实现中,T::pvf()接受的是嵌套在T中的P的指针,所以,需要提供一个调整块,把this指针调整到T::t1之后(该处即是P在T中的位置)。

5.6 特殊成员函数

本节讨论编译器合成到特殊成员函数中的隐藏代码。

5.6.1 构造函数和析构函数

正如我们所见,在构造和析构过程中,有时需要初始化一些隐藏的成员变量。最坏的情况下,一个构造函数要执行如下操作:

  * 如果是“最终派生类”,初始化vbptr成员变量,调用虚基类的构造函数;
  * 调用非虚基类的构造函数
  * 调用成员变量的构造函数
  * 初始化虚函数表成员变量
  * 执行构造函数体中,程序所定义的其他初始化代码

(注意:一个“最终派生类”的实例,一定不是嵌套在其他派生类实例中的基类实例)

所以,如果你有一个包含虚函数的很深的继承层次,即使该继承层次由单继承构成,对象的构造可能也需要很多针对虚函数表的初始化。
反之,析构函数必须按照与构造时严格相反的顺序来“肢解”一个对象。

 * 合成并初始化虚函数表成员变量
 * 执行析构函数体中,程序定义的其他析构代码
 * 调用成员变量的析构函数(按照相反的顺序)
 * 调用直接非虚基类的析构函数(按照相反的顺序)
 * 如果是“最终派生类”,调用虚基类的析构函数(按照相反顺序)

在VC++中,有虚基类的类的构造函数接受一个隐藏的“最终派生类标志”,标示虚基类是否需要初始化。对于析构函数,VC++采用“分层析构模型”,代码中加入一个隐藏的析构函数,该函数被用于析构包含虚基类的类(对于“最终派生类”实例而言);代码中再加入另一个析构函数,析构不包含虚基类的类。前一个析构函数调用后一个。

5.6.2 虚析构函数与delete操作符

考虑结构V和W。
 
struct V {
   virtual ~V();
};
 
  struct W : V {
   operator delete();
};
 
析构函数可以为虚。一个类如果有虚析构函数的话,将会象有其他虚函数一样,拥有一个虚函数表指针,虚函数表中包含一项,其内容为指向对该类适用的虚析构函数的地址。这些机制和普通虚函数相同。虚析构函数的特别之处在于:当类实例被销毁时,虚析构函数被隐含地调用。调用地(delete发生的地方)虽然不知道销毁的动态类型,然而,要保证调用对该类型合适的delete操作符。例如,当pv指向W的实例时,当W::~W被调用之后,W实例将由W类的delete操作符来销毁。
 
V* pv = new V;
delete pv;   // pv->~V::V(); // use ::operator delete()
pv = new W;
delete pv;   // pv->~W::W(); // use W::operator delete()
pv = new W;
::delete pv; // pv->~W::W(); // use ::operator delete()
译者注:
 V没有定义delete操作符,delete时使用函数库的delete操作符;
 W定义了delete操作符,delete时使用自己的delete操作符;
 可以用全局范围标示符显示地调用函数库的delete操作符。

为了实现上述语意,VC++扩展了其“分层析构模型”,从而自动创建另一个隐藏的析构帮助函数——“deleting析构函数”,然后,用该函数的地址来替换虚函数表中“实际”虚析构函数的地址。析构帮助函数调用对该类合适的析构函数,然后为该类有选择性地调用合适的delete操作符。

6 数组

堆上分配空间的数组使虚析构函数进一步复杂化。问题变复杂的原因有两个:
1、 堆上分配空间的数组,由于数组可大可小,所以,数组大小值应该和数组一起保存。因此,堆上分配空间的数组会分配额外的空间来存储数组元素的个数;
2、 当数组被删除时,数组中每个元素都要被正确地释放,即使当数组大小不确定时也必须成功完成该操作。然而,派生类可能比基类占用更多的内存空间,从而使正确释放比较困难。
 
struct WW : W { int w1; };
pv = new W[m];
delete [] pv; // delete m W's  (sizeof(W)  == sizeof(V))
pv = new WW[n];
delete [] pv; // delete n WW's (sizeof(WW) >  sizeof(V))
译者注:WW从W继承,增加了一个成员变量,因此,WW占用的内存空间比W大。然而,不管指针pv指向W的数组还是WW的数组,delete[]都必须正确地释放WW或W对象占用的内存空间。

虽然从严格意义上来说,数组delete的多态行为C++标准并未定义,然而,微软有一些客户要求实现该行为。因此,在MSC++中,该行为是用另一个编译器生成的虚析构帮助函数来完成。该函数被称为“向量delete析构函数”(因其针对特定的类定制,比如WW,所以,它能够遍历数组的每个元素,调用对每个元素适用的析构函数)。

7 异常处理

简单说来,异常处理是C++标准委员会工作文件提供的一种机制,通过该机制,一个函数可以通知其调用者“异常”情况的发生,调用者则能据此选择合适的代码来处理异常。该机制在传统的“函数调用返回,检查错误状态代码”方法之外,给程序提供了另一种处理错误的手段。

因为C++是面向对象的语言,很自然地,C++中用对象来表达异常状态。并且,使用何种异常处理也是基于“抛出的”异常对象的静态或动态类型来决定的。不光如此,既然C++总是保证超出范围的对象能够被正确地销毁,异常实现也必须保证当控制从异常抛出点转换到异常“捕获”点时(栈展开),超出范围的对象能够被自动、正确地销毁。
考虑如下例子:
 
struct X { X(); }; // exception object class
struct Z { Z(); ~Z(); }; // class with a destructor
extern void recover(const X&);
void f(int), g(int);

int main() {
   try {
      f(0);
   } catch (const X& rx) {
      recover(rx);
   }
   return 0;
}

void f(int i) {
   Z z1;
   g(i);
   Z z2;
   g(i-1);
}

void g(int j) {
   if (j < 0)
      throw X();
}
译者注:X是异常类,Z是带析构函数的工作类,recover是错误处理函数,f和g一起产生异常条件,g实际抛出异常。

这段程序会抛出异常。在main中,加入了处理异常的try & catch框架,当调用f(0)时,f构造z1,调用g(0)后,再构造z2,再调用g(-1),此时g发现参数为负,抛出X异常对象。我们希望在某个调用层次上,该异常能够得到处理。既然g和f都没有建立处理异常的框架,我们就只能希望main函数建立的异常处理框架能够处理X异常对象。实际上,确实如此。当控制被转移到main中异常捕获点时,从g中的异常抛出点到main中的异常捕获点之间,该范围内的对象都必须被销毁。在本例中,z2和z1应该被销毁。

谈到异常处理的具体实现方式,一般情况下,在抛出点和捕获点都使用“表”来表述能够捕获异常对象的类型;并且,实现要保证能够在特定的捕获点真正捕获特定的异常对象;一般地,还要运用抛出的对象来初始化捕获语句的“实参”。通过合理地选择编码方案,可以保证这些表格不会占用过多的内存空间。

异常处理的开销到底如何?让我们再考虑一下函数f。看起来f没有做异常处理。f确实没有包含try,catch,或者是throw关键字,因此,我们会猜异常处理应该对f没有什么影响。错!编译器必须保证一旦z1被构造,而后续调用的任何函数向f抛回了异常,异常又出了f的范围时,z1对象能被正确地销毁。同样,一旦z2被构造,编译器也必须保证后续抛出异常时,能够正确地销毁z2和z1。

要实现这些“展开”语意,编译器必须在后台提供一种机制,该机制在调用者函数中,针对调用的函数抛出的异常动态决定异常环境(处理点)。这可能包括在每个函数的准备工作和善后工作中增加额外的代码,在最糟糕的情况下,要针对每一套对象初始化的情况更新状态变量。例如,上述例子中,z1应被销毁的异常环境当然与z2和z1都应该被销毁的异常环境不同,因此,不管是在构造z1后,还是继而在构造z2后,VC++都要分别在状态变量中更新(存储)新的值。

所有这些表,函数调用的准备和善后工作,状态变量的更新,都会使异常处理功能造成可观的内存空间和运行速度开销。正如我们所见,即使在没有使用异常处理的函数中,该开销也会发生。

幸运的是,一些编译器可以提供编译选项,关闭异常处理机制。那些不需要异常处理机制的代码,就可以避免这些额外的开销了。

8 小结

好了,现在你可以写C++编译器了(开个玩笑)。
在本文中,我们讨论了许多重要的C++运行实现问题。我们发现,很多美妙的C++语言特性的开销很低,同时,其他一些美妙的特性(译者注:主要是和“虚”字相关的东西)将造成较大的开销。C++很多实现机制都是在后台默默地为你工作。一般说来,单独看一段代码时,很难衡量这段代码造成的运行时开销,必须把这段代码放到一个更大的环境中来考察,运行时开销问题才能得到比较明确的答案。


posted @ 2012-01-29 14:47 niomaa 阅读(155) | 评论 (0)编辑 收藏