(2) c++
void foo(void)
{
int i, j;
for (i = 0; i < 16; i++) j = j + i;
}delphi 3生成的代码(打开优化): 字节数 时钟周期
00424aa9 33c0 xor eax,eax 1
00424aab 40 inc eax 1
00424aac 83f810 cmp eax,0x10 1
00424aaf 75fa jnz -0x06 0 (可并行)
-----------------
8 3
c++ builder 5生成的代码(最大速度优化):
00401535 33c0 xor eax,eax 1
00401537 40 inc eax 1
00401538 83f810 cmp eax,0x10 1
0040153b 7cfa jl -0x06 0 (可并行)
-----------------
8 3visual c++ 5生成的代码(最大速度优化):
27: for (i = 0; i < 16; i ++)
00401205 mov ecx,dowrd ptr [j] 1
00401208 xor eax,eax 0 (可并行)
28: {
29: j = j + i;
0040120a add ecx,eax 1
0040120c inc eax 1
0040120d cmp eax,10h 1
00401210 jl foo(0x0040120a)+0ah 0 (可并行)
00401212 mov dword ptr [j],ecx 0/1 (取决于上一条指令的分支预测情况)
30: };
-----------------
16 4.2 (假定分支预测准确度80%)vc++ 5的最小代码优化生成也有11个字节:
27: for (i = 0; i < 16; i ++)
00401205 xor eax,eax 1
28: {
29: j = j + i;
00401207 add dword ptr [j],eax 1
0040120a inc eax 1
0040120b cmp eax,10h 1
0040121e jl foo(0x00401207)+7 0 (可并行)
30: };
-----------------
11 4注:
(1) delphi/c++ builder的结果是用turbo debugger直接反汇编的,vc++ 5的结果是从
集成环境的源级调试得到的。
(2) 时钟周期数以pentium处理器为例,实际上,对于没有并行执行单元的cpu(比如
386/486和nx586等)vc++ 5生成的代码速度还要更慢一些。
(3) 分支预测准确度源自intel的"pentium optimization reference"。不过与具体程
序密切相关,一般来说程序中的条件转移指令越密集则分支预测准确度越低。可以看出,delphi/c++ builder的这段程序有1~1.2个时钟周期的优势。这主要是因为
delphi/c++ builder的编译器比较智能,根本不编译无用的废语句。(有趣的是,对于这段程序而言,vc++ 5的最大速度优化反而不如最小代码优化生成的
代码运行速度快。)不要以为1~1.2个时钟周期不算什么,整个程序的快与慢就是这样一个个时钟周期积累出来的。而且就这几条指令而言相当于快25%~28.6%,是非常可观的数字。我没有用vc++ 6测试(我从vc++ 5以后不再使用vc了,因为c++ builder 5能完全兼容vc --- 这种兼容性从c++ builder 3开始就有了,不过一开始并不完善),不知道是否有改进。有人有兴趣的话请测试一下。
有兴趣的话,可以去jake's code efficiency challenge(http://www.xnet.com/~johnjac)
看一看。那有代码运行性能挑战。目前delphi/c++ builder在6项测试中保持5项领先。(ps:delphi 2就曾在1996年的pc week的性能测试中击败过vc++ 4.2)
2. 语言特性
首先我不想评价所谓“pascal是玩具语言”这种无知的说法。某些连basic都用不好的人是不可能正确评价其它语言的优劣的。至于“只配高中生使用”就更加可笑了:
peter norton没上过大学,id software的john carmack没上过大学,你不服气?!
请不要嘲笑高中生,大多数程序员可能永远也达不到这些“高中生”的水平。创造性工作需要的是天才,你认为天才相当于什么学位?:-)
(1) 预处理,宏以及.h文件
object pascal不支持预处理,其实是不需要。无法直接编译源代码的编译器才需要预处理器的支持(用于翻译/规范源程序(也包括.h之类)以利于编译)。预处理器的出现是因为当初ken thompson和dennis ritchie要在只有256k内存的pdp-11上实现c编译器难度很大,才采取的折衷办法。现代大多数c/c++产品已经把预处理器包含在编译器中了。
(ps:c中采用尽可能短的关键字/运算符也是由于这个历史原因)
至于macro和.h则应该说是垃圾特性,只是由于兼容性的考虑才保留下来的。ansi/iso 
c/c++规范中明确建议:“不要使用macro和.h,应该使用程序中的常量定义和函数替
代”。因为macro和.h不是c/c++的语言特性(这是真的!),没有明确统一的语法义。
还会导致编译速度降低,另外由于macro在每个使用的地方被展开(不是调用),大量使用macro会使生成的代码臃肿。
(2) 集合,子界类型
c++不支持这些object pascal的原生类型(编译器能直接识别的)。但可以用类来模拟,毕竟c++的对象结构是最复杂灵活的(ada除外)。不过性能有损失。
(3) 枚举类型
object pascal不支持为每个枚举元素指定值。
例如c/c++中可以定义:enum aweek {sun = 1, mon, tue ...};
object pascal中只能定义:aweek = (sun, mon, tue ...);
(4) 数组
c/c++不支持object pascal中指定下标的数组,下标只能从0开始。
(5) 结构
object pascal不支持struct(在pascal中称为record)中的位域(bitfield)。bitfield
可以bit为单位(不需要整字节)来存储结构成员,可以减小结构的存储空间。不过存取效率会有所降低。
(6) 字符串
字符串处理是object pascal的强项之一。能够支持灵活高效的串处理。严格意义上讲,c/c++不能算支持原生的字符串类型。char *和char[]更近似于用户自定义类型,因为编译器不支持字符串的内存自动分配和回收,需要用户自己调用malloc()和free()。
object pascal也支持c/c++风格的字符串(称为pchar)。不过string类型更加强大。从实现上来看,object pascal的string类型使用前缀表示串长度(1字节前缀的short
string和4字节前缀的long string,两种string自动兼容,并且long string也兼容
pchar),c/c++中的char *和char[]使用后缀chr(0)表示串结束。不同的表示方法对串处理性能有很大的影响:对于大量,复杂的字符串操作,用object pascal可以写出比c/c++快几十倍的程序(许多用pascal写的pascal编译器,比如free pascal,
pascal pro等,虽然技术水平一般,但编译速度也很快,在某种程度上也得益于pascal的字符串处理效率)。比如取串长度函数length/strlen(),object pascal的实现只需要一条mov指令,而c/c++的实现则需要进行重复串扫描直到找到结尾0为止。object pascal的string类型在支持unicode字符方面也有优势。要知道c/c++的字符串给现代操作系统支持unicode字符带来了很大的困扰,比如串'abc'的unicode表示为:
41 00 42 00 43 00,这使c/c++程序根本无法处理这种字符串。虽然修改编译器可以很容易解决这个问题,但光修改编译器是不够的,还要修改操作系统,否则以前的大量c/c++程序根本无法在新操作系统上使用(这简直是灾难 --- 你连notepad都没了,怎么办?:-)。windows采用凡是涉及字符串处理的api都提供两套的解决方案。比如textout,有用于处理ascii字符的textouta和用于处理unicode字符的textoutw。而unix/linux采用另一种办法:凡是涉及字符串处理的api都使用utf8压缩编码(一种类似于rtf的编码方法:凡是ascii字符都直接存储,多字节字符则用\进行转义),虽然(勉强)保证了兼容性却也代价不小。
(ps:c++中的string/ansistring是用类模拟的,所以性能...)
(7) 多重继承
毫无疑问,object pascal不支持多重继承;并且也看不出borland有增加这一特性的意向(其实增加是轻而易举的)。object pascal通过接口(interface)实现多重继承。
interface不仅可以引入用object pascal实现的对象,也可以引入其他语言实现的
com/dcom/corba对象。你真的需要多重继承吗?我想大多数程序员和我一样都从来没有使用过多重继承(连vcl这么强大灵活的体系结构都根本没有用到多重继承)。
(ps:java和delphi一样不支持多重继承,也使用interface来实现多重继承。其实这并不奇怪:jdk 1.2和java 2主要是由borland开发的,sun只挂名而已。不信你看java类库是不是和vcl很象。:-)
(8) 对象模板
object pascal不支持对象模板。因为对象模板不过是宏的语言实现而已(宏本身不是
c/c++的语言特性)。
(9) 重载
object pascal支持函数/过程的重载,不支持运算符重载。c++全部支持。
(ps:我个人倾向于object pascal应该增加对运算符重载的支持)
(10) 位及逻辑操作
object pascal和c/c++在这方面没什么差别。
c/c++的&,|,~,^,>>,<<,&&,||,!等效于object pascal的and,or,not,xor,shr,shl(and,or,not,xor既用于位操作也用于逻辑操作)。不过c/c++不支持逻辑xor(a xor b = a and not b or not a and b,还是可以实现的)。
(11) 风格
其实这是我更倾向于使用delphi的一个重要原因(由于工作的原因,我也经常使用c++和汇编)。就象有些文章所说的:“object pascal和c++是同一重量级的语言”,确实难分轩轾,差别反而主要是在风格上。c++强调灵活,而object pascal更注重整洁和优美。
《程序设计语言:设计与实现》一书的作者也称赞pascal是“一种极优美的语言”。有人因此认为pascal“笨拙”。其实应该是“大道至简”。我认为即使用c++写程序也还是工工整整的好,不要卖弄技巧。只有水平不高不低的程序员才喜欢卖弄技巧(水平太低的卖弄不了,太高的又不愿卖弄了)。就象有人评李昌镐的棋“平淡”,但马晓春再怎么“鬼才”也只能甘拜下风。
上面说的其实都是c++ vs object pascal。不过也适用于vc++ vs delphi。
(ps:vc++其实并未实现全部ansi/iso c++ 95规范(目前的最新标准)的特性(所以有人戏称之为c+)。而c++ builder则完全兼容ansi/iso c++ 95规范,并支持at&t(c的诞生地)和unix v的全部c++扩展特性。有人称“m$坚持工业标准,borland随意修改”,这是不对的。delphi也全兼容ansi/iso pascal 1983/92规范,以及apple object pascal(用过code warrior professional的应该知道apple的object pascal)。
3. 功能及其他
(1) 易用性
毫无疑问delphi有巨大优势,这不用多说了吧。
(ps:delphi的真正伟大之处在于并不因为易用而降低技术水准。你需要复杂性就有复杂性,你需要灵活性就有灵活性;不用可视化也一样写程序(可视化只是object pascal对象结构的另一面),不用vcl也一样写程序)
(2) 适用范围
vc++几乎