什么是LDAP?

什么时候该用LDAP存储数据？

LDAP目录树的结构

现在LDAP技术不仅发展得很快而且也是激动人心的。在企业范围内实现LDAP可以让运行在几乎所有计算机平台上的所有的应用程序从LDAP目录中获取信息。LDAP目录中可以存储各种类型的数据：电子邮件地址、邮件路由信息、人力资源数据、公用密匙、联系人列表，等等。通过把LDAP目录作为系统集成中的一个重要环节，可以简化员工在企业内部查询信息的步骤，甚至连主要的数据源都可以放在任何地方。如果Oracle、Sybase、Informix或Microsoft SQL数据库中已经存储了类似的数据，那么LDAP和这些数据库到底有什么不同呢？是什么让它更具优势？请继续读下去吧！

什么是LDAP?

LDAP的英文全称是Lightweight Directory Access Protocol，一般都简称为LDAP。它是基于X.500标准的，但是简单多了并且可以根据需要定制。与X.500不同，LDAP支持TCP/IP，这对访问Internet是必须的。LDAP的核心规范在RFC中都有定义，所有与LDAP相关的RFC都可以在LDAPman RFC网页中找到。

怎么使用LDAP这个术语呢？

在日常交谈中，你可能会听到有些人这么说：“我们要把那些东西存在LDAP中吗？”，或者“从LDAP数据库中取出那些数据！”，又或者“我们怎么把LDAP和关系型数据库集成在一起？”。严格地说，LDAP根本不是数据库而是用来访问存储在信息目录（也就是LDAP目录）中的信息的协议。更为确切和正式的说法应该是象这样的：“通过使用LDAP，可以在信息目录的正确位置读取（或存储）数据”。但是，也没有必要吹毛求疵，尽管表达得不够准确，我们也都知道对方在说什么。

LDAP目录是数据库吗？

就象Sybase、Oracle、Informix或Microsoft的数据库管理系统（DBMS）是用于处理查询和更新关系型数据库那样，LDAP服务器也是用来处理查询和更新LDAP目录的。换句话来说LDAP目录也是一种类型的数据库，但是不是关系型数据库。不象被设计成每分钟需要处理成百上千条数据变化的数据库，例如：在电子商务中经常用到的在线交易处理（OLTP）系统，LDAP主要是优化数据读取的性能。

LDAP目录的优势

现在该说说LDAP目录到底有些什么优势了。现在LDAP的流行是很多因数共同作用的结果。我在这里说的不过是一些基本的原因，请你注意一下这不过是一小部分原因。

可能LDAP最大的优势是：可以在任何计算机平台上，用很容易获得的而且数目不断增加的LDAP的客户端程序访问LDAP目录。而且也很容易定制应用程序为它加上LDAP的支持。

LDAP协议是跨平台的和标准的协议，因此应用程序就不用为LDAP目录放在什么样的服务器上操心了。实际上，LDAP得到了业界的广泛认可，因为它是Internet的标准。产商都很愿意在产品中加入对LDAP的支持，因为他们根本不用考虑另一端（客户端或服务端）是怎么样的。LDAP服务器可以是任何一个开发源代码或商用的LDAP目录服务器（或者还可能是具有LDAP界面的关系型数据库），因为可以用同样的协议、客户端连接软件包和查询命令与LDAP服务器进行交互。与LDAP不同的是，如果软件产商想在软件产品中集成对DBMS的支持，那么通常都要对每一个数据库服务器单独定制。

不象很多商用的关系型数据库，你不必为LDAP的每一个客户端连接或许可协议付费。

大多数的LDAP服务器安装起来很简单，也容易维护和优化。

LDAP服务器可以用“推”或“拉”的方法复制部分或全部数据，例如：可以把数据“推”到远程的办公室，以增加数据的安全性。复制技术是内置在LDAP服务器中的而且很容易配置。如果要在DBMS中使用相同的复制功能，数据库产商就会要你支付额外的费用，而且也很难管理。

LDAP允许你根据需要使用ACI（一般都称为ACL或者访问控制列表）控制对数据读和写的权限。例如，设备管理员可以有权改变员工的工作地点和办公室号码，但是不允许改变记录中其它的域。ACI可以根据谁访问数据、访问什么数据、数据存在什么地方以及其它对数据进行访问控制。因为这些都是由LDAP目录服务器完成的，所以不用担心在客户端的应用程序上是否要进行安全检查。

LDAP对于这样存储这样的信息最为有用，也就是数据需要从不同的地点读取，但是不需要经常更新。例如，这些信息存储在LDAP目录中是十分有效的：

l        公司员工的电话号码簿和组织结构图

l        客户的联系信息

l        计算机管理需要的信息，包括NIS映射、email假名，等等

l        软件包的配置信息

l        公用证书和安全密匙

什么时候该用LDAP存储数据？

大多数的LDAP服务器都为读密集型的操作进行专门的优化。因此，当从LDAP服务器中读取数据的时候会比从专门为OLTP优化的关系型数据库中读取数据快一个数量级。也是因为专门为读的性能进行优化，大多数的LDAP目录服务器并不适合存储需要需要经常改变的数据。例如，用LDAP服务器来存储电话号码是一个很好的选择，但是它不能作为电子商务站点的数据库服务器。

如果下面每一个问题的答案都是“是”，那么把数据存在LDAP中就是一个好主意。

l        需要在任何平台上都能读取数据吗？

l        每一个单独的记录项是不是每一天都只有很少的改变？

l        可以把数据存在平面数据库（flat database）而不是关系型数据库中吗？换句话来说，也就是不管什么范式不范式的，把所有东西都存在一个记录中（差不多只要满足第一范式）。

最后一个问题可能会唬住一些人，其实用平面数据库去存储一些关系型的数据也是很一般的。例如，一条公司员工的记录就可以包含经理的登录名。用LDAP来存储这类信息是很方便的。一个简单的判断方法：如果可以把保数据存在一张张的卡片里，就可以很容易地把它存在LDAP目录里。

LDAP目录树的结构

LDAP目录以树状的层次结构来存储数据。如果你对自顶向下的DNS树或UNIX文件的目录树比较熟悉，也就很容易掌握LDAP目录树这个概念了。就象DNS的主机名那样，LDAP目录记录的标识名（Distinguished Name，简称DN）是用来读取单个记录，以及回溯到树的顶部。后面会做详细地介绍。

为什么要用层次结构来组织数据呢？原因是多方面的。下面是可能遇到的一些情况：

l        如果你想把所有的美国客户的联系信息都“推”到位于到西雅图办公室（负责营销）的LDAP服务器上，但是你不想把公司的资产管理信息“推”到那里。

l        你可能想根据目录树的结构给予不同的员工组不同的权限。在下面的例子里，资产管理组对“asset-mgmt”部分有完全的访问权限，但是不能访问其它地方。

l        把LDAP存储和复制功能结合起来，可以定制目录树的结构以降低对WAN带宽的要求。位于西雅图的营销办公室需要每分钟更新的美国销售状况的信息，但是欧洲的销售情况就只要每小时更新一次就行了。

刨根问底：基准DN

LDAP目录树的最顶部就是根，也就是所谓的“基准DN”。基准DN通常使用下面列出的三种格式之一。假定我在名为FooBar的电子商务公司工作，这家公司在Internet上的名字是foobar.com。

o="FooBar, Inc.", c=US

（以X.500格式表示的基准DN）

在这个例子中，o=FooBar, Inc. 表示组织名，在这里就是公司名的同义词。c=US 表示公司的总部在美国。以前，一般都用这种方式来表示基准DN。但是事物总是在不断变化的，现在所有的公司都已经（或计划）上Internet上。随着Internet的全球化，在基准DN中使用国家代码很容易让人产生混淆。现在，X.500格式发展成下面列出的两种格式。

o=foobar.com

（用公司的Internet地址表示的基准DN）

这种格式很直观，用公司的域名作为基准DN。这也是现在最常用的格式。

dc=foobar, dc=com

（用DNS域名的不同部分组成的基准DN）

就象上面那一种格式，这种格式也是以DNS域名为基础的，但是上面那种格式不改变域名（也就更易读），而这种格式把域名：foobar.com分成两部分 dc=foobar, dc=com。在理论上，这种格式可能会更灵活一点，但是对于最终用户来说也更难记忆一点。考虑一下foobar.com这个例子。当foobar.com和gizmo.com合并之后，可以简单的把“dc=com”当作基准DN。把新的记录放到已经存在的dc=gizmo, dc=com目录下，这样就简化了很多工作（当然，如果foobar.com和wocket.edu合并，这个方法就不能用了）。如果LDAP服务器是新安装的，我建议你使用这种格式。再请注意一下，如果你打算使用活动目录（Actrive Directory），Microsoft已经限制你必须使用这种格式。

更上一层楼：在目录树中怎么组织数据

在UNIX文件系统中，最顶层是根目录（root）。在根目录的下面有很多的文件和目录。象上面介绍的那样，LDAP目录也是用同样的方法组织起来的。

在根目录下，要把数据从逻辑上区分开。因为历史上（X.500）的原因，大多数LDAP目录用OU从逻辑上把数据分开来。OU表示“Organization Unit”，在X.500协议中是用来表示公司内部的机构：销售部、财务部，等等。现在LDAP还保留ou=这样的命名规则，但是扩展了分类的范围，可以分类为：ou=people, ou=groups, ou=devices，等等。更低一级的OU有时用来做更细的归类。例如：LDAP目录树（不包括单独的记录）可能会是这样的：

    dc=foobar, dc=com

        ou=customers

            ou=asia

            ou=europe

            ou=usa

        ou=employees

        ou=rooms

        ou=groups

        ou=assets-mgmt

        ou=nisgroups

        ou=recipes

单独的LDAP记录

作为例子的一个单独的数据项

LDAP复制

安全和访问控制

CVS是一个C/S系统，多个开发人员通过一个中心版本控制系统来记录文件版本，从而达到保证文件同步的目的。工作模式如下：

       CVS服务器（文件版本库）
     /     |       \
     （版 本 同 步）
   /       |         \
开发者1  开发者2   开发者3

作为一般开发人员挑选2,6看就可以了，CVS的管理员则更需要懂的更多一些，最后还简单介绍了一些Windows下的cvs客户端使用，CVS远程用户认证的选择及与BUG跟踪系统等开发环境的集成问题。

1. CVS环境初始化：CVS环境的搭建 管理员
2. CVS的日常使用：日常开发中最常用的CVS命令， 开发人员 管理员
3. CVS的分支开发：项目按照不同进度和目标并发进行 管理员
4. CVS的用户认证：通过SSH的远程用户认证，安全，简单 管理员
5. CVSWEB：CVS的WEB访问界面大大提高代码版本比较的效率 管理员
6. CVS TAG：将$Id$ 加入代码注释中，方便开发过程的跟踪开发人员
7. CVS vs VSS: CVS和Virsual SourceSafe的比较 开发人员 管理员
8. WinCVS: 通过SSH认证的WinCVS认证设置
9. 基于CVSTrac的小组开发环境搭建：通过CVSTrac实现web界面的CVS用户管理,集成的BUG跟踪和WIKI交流
10. CVS中的用户权限管理：基于系统用户的CVS权限管理和基于CVSROOT/passwd的虚拟用户管理
    

一个系统20%的功能往往能够满足80%的需求，CVS也不例外，以下是CVS最常用的功能，可能还不到它全部命令选项的20%，作为一般开发人员平时会用cvs update和cvs commit就够了，更多的需求在实际应用过程中自然会出现，不时回头看看相关文档经常有意外的收获。

CVS环境初始化

tcsh
setenv CVSROOT /path/to/cvsroot
bash
CVSROOT=/path/to/cvsroot ; export CVSROOT

后面还提到远程CVS服务器的设置：
CVSROOT=:ext:$USER@test.server.address#port:/path/to/cvsroot CVS_RSH=ssh; export CVSROOT CVS_RSH

初始化：CVS版本库的初始化。
cvs init

一个项目的首次导入
cvs import -m "write some comments here" project_name vendor_tag release_tag
执行后：会将所有源文件及目录导入到/path/to/cvsroot/project_name目录下
vender_tag: 开发商标记
release_tag: 版本发布标记

项目导出：将代码从CVS库里导出
cvs checkout project_name
cvs 将创建project_name目录，并将最新版本的源代码导出到相应目录中。这个checkout和Virvual SourceSafe中的check out不是一个概念，相对于Virvual SourceSafe的check out是cvs update， check in是cvs commit。

CVS的日常使用

注意：第一次导出以后，就不是通过cvs checkout来同步文件了，而是要进入刚才cvs checkout project_name导出的project_name目录下进行具体文件的版本同步（添加，修改，删除）操作。

将文件同步到最新的版本
cvs update
不制定文件名，cvs将同步所有子目录下的文件，也可以制定某个文件名/目录进行同步
cvs update file_name
最好每天开始工作前或将自己的工作导入到CVS库里前都要做一次，并养成“先同步 后修改”的习惯，和Virvual SourceSafe不同，CVS里没有文件锁定的概念，所有的冲突是在commit之前解决，如果你修改过程中，有其他人修改并commit到了CVS 库中，CVS会通知你文件冲突，并自动将冲突部分用
>>>>>>
content on cvs server
<<<<<<
content in your file
>>>>>>
标记出来，由你确认冲突内容的取舍。
版本冲突一般是在多个人修改一个文件造成的，但这种项目管理上的问题不应该指望由CVS来解决。

确认修改写入到CVS库里
cvs commit -m "write some comments here" file_name

注意：CVS的很多动作都是通过cvs commit进行最后确认并修改的，最好每次只修改一个文件。在确认的前，还需要用户填写修改注释，以帮助其他开发人员了解修改的原因。如果不用写-m "comments"而直接确认`cvs commit file_name` 的话，cvs会自动调用系统缺省的文字编辑器(一般是vi)要求你写入注释。
注释的质量很重要：所以不仅必须要写，而且必须写一些比较有意义的内容：以方便其他开发人员能够很好的理解
不好的注释，很难让其他的开发人员快速的理解：比如： -m "bug fixed" 甚至 -m ""
好的注释，甚至可以用中文: -m "在用户注册过程中加入了Email地址校验"

修改某个版本注释：每次只确认一个文件到CVS库里是一个很好的习惯，但难免有时候忘了指定文件名，把多个文件以同样注释commit到CVS库里了，以下命令可以允许你修改某个文件某个版本的注释：
cvs admin -m 1.3:"write some comments here" file_name

添加文件
创建好新文件后，比如：touch new_file
cvs add new_file
注意：对于图片，Word文档等非纯文本的项目，需要使用cvs add -kb选项按2进制文件方式导入(k表示扩展选项，b表示binary)，否则有可能出现文件被破坏的情况
比如：
cvs add -kb new_file.gif
cvs add -kb readme.doc

如果关键词替换属性在首次导入时设置错了怎么办？
cvs admin -kkv new_file.css

然后确认修改并注释
cvs ci -m "write some comments here"

删除文件
将某个源文件物理删除后，比如：rm file_name
cvs rm file_name
然后确认修改并注释
cvs ci -m "write some comments here"
以上面前2步合并的方法为：
cvs rm -f file_name
cvs ci -m "why delete file"
注意：很多cvs命令都有缩写形式：commit=>ci; update=>up; checkout=>co/get; remove=>rm;

添加目录
cvs add dir_name

查看修改历史
cvs log file_name
cvs history file_name

查看当前文件不同版本的区别
cvs diff -r1.3 -r1.5 file_name
查看当前文件（可能已经修改了）和库中相应文件的区别
cvs diff file_name
cvs的web界面提供了更方便的定位文件修改和比较版本区别的方法，具体安装设置请看后面的cvsweb使用

正确的通过CVS恢复旧版本的方法：
如果用cvs update -r1.2 file.name
这个命令是给file.name加一个STICK TAG： "1.2" ，虽然你的本意只是想将它恢复到1.2版本
正确的恢复版本的方法是：cvs update -p -r1.2 file_name >file_name
如果不小心已经加成STICK TAG的话：用cvs update -A 解决

移动文件/文件重命名
cvs里没有cvs move或cvs rename，因为这两个操作是可以由先cvs remove old_file_name，然后cvs add new_file_name实现的。

删除/移动目录
最方便的方法是让管理员直接移动，删除CVSROOT里相应目录（因为CVS一个项目下的子目录都是独立的，移动到$CVSROOT目录下都可以作为新的独立项目：好比一颗树，其实砍下任意一枝都能独立存活），对目录进行了修改后，要求其开发人员重新导出项目cvs checkout project_name 或者用cvs update -dP同步。

项目发布导出不带CVS目录的源文件
做开发的时候你可能注意到了，每个开发目录下，CVS都创建了一个CVS/目录。里面有文件用于记录当前目录和CVS库之间的对应信息。但项目发布的时候你一般不希望把文件目录还带着含有CVS信息的CVS目录吧，这个一次性的导出过程使用cvs export命令，不过export只能针对一个TAG或者日期导出，比如：
cvs export -r release1 project_name
cvs export -D 20021023 project_name
cvs export -D now project_name

CVS Branch：项目多分支同步开发

cvs tag release_1_0

开始一个新的里程碑：
cvs commit -r 2 标记所有文件开始进入2.x的开发

注意：CVS里的revsion和软件包的发布版本可以没有直接的关系。但所有文件使用和发布版本一致的版本号比较有助于维护。

版本分支的建立
在开发项目的2.x版本的时候发现1.x有问题，但2.x又不敢用，则从先前标记的里程碑：release_1_0导出一个分支 release_1_0_patch
cvs rtag -b -r release_1_0 release_1_0_patch proj_dir

一些人先在另外一个目录下导出release_1_0_patch这个分支：解决1.0中的紧急问题，
cvs checkout -r release_1_0_patch
而其他人员仍旧在项目的主干分支2.x上开发

在release_1_0_patch上修正错误后，标记一个1.0的错误修正版本号
cvs tag release_1_0_patch_1

如果2.0认为这些错误修改在2.0里也需要，也可以在2.0的开发目录下合并release_1_0_patch_1中的修改到当前代码中：
cvs update -j release_1_0_patch_1

CVS的远程认证通过SSH远程访问CVS

常见的登陆格式如下：
cvs -d :pserver:cvs_user_name@cvs.server.address:/path/to/cvsroot login
例子：
cvs -d :pserver:cvs@samba.org:/cvsroot login

不是很安全，因此一般是作为匿名只读CVS访问的方式。从安全考虑，通过系统本地帐号认证并通过SSH传输是比较好的办法，通过在客户机的 /etc/profile里设置一下内容：
CVSROOT=:ext:$USER@cvs.server.address#port:/path/to/cvsroot CVS_RSH=ssh; export CVSROOT CVS_RSH
所有客户机所有本地用户都可以映射到CVS服务器相应同名帐号了。

比如:

CVS服务器是192.168.0.3，上面CVSROOT路径是/home/cvsroot，另外一台开发客户机是192.168.0.4，如果 tom在2台机器上都有同名的帐号，那么从192.168.0.4上设置了：
export CVSROOT=:ext:tom@192.168.0.3:/home/cvsroot
export CVS_RSH=ssh
tom就可以直接在192.168.0.4上对192.168.0.3的cvsroot进行访问了（如果有权限的话）
cvs checkout project_name
cd project_name
cvs update
...
cvs commit

如果CVS所在服务器的SSH端口不在缺省的22，或者和客户端与CVS服务器端SSH缺省端口不一致，有时候设置了：
:ext:$USER@test.server.address#port:/path/to/cvsroot

仍然不行，比如有以下错误信息：
ssh: test.server.address#port: Name or service not known
cvs [checkout aborted]: end of file from server (consult above messages if any)

解决的方法是做一个脚本指定端口转向（不能使用alias，会出找不到文件错误）：
创建一个/usr/bin/ssh_cvs文件，假设远程服务器的SSH端口是非缺省端口：34567
#!/bin/sh
/usr/bin/ssh -p 34567 "$@"
然后：chmod +x /usr/bin/ssh_cvs
并CVS_RSH=ssh_cvs; export CVS_RSH

注意：port是指相应服务器SSH的端口，不是指cvs专用的pserver的端口

CVSWEB：提高文件浏览效率

使用的样例可以看：http://www.freebsd.org/cgi/cvsweb.cgi

CVSWEB的下载：CVSWEB从最初的版本已经演化出很多功能界面更丰富的版本，这个是我个人感觉安装设置比较方便的：
原先在：http://www.spaghetti-code.de/software/linux/cvsweb/，但目前已经删除，目前仍可以在本站下载CVSWEB，其实最近2年FreeBSD的CVSWeb项目已经有了更好的发展吧，而当初没有用FreeBSD那个版本主要就是因为没有彩色的文件Diff功能。
下载解包：
tar zxf cvsweb.tgz
把配置文件cvsweb.conf放到安全的地方（比如和apache的配置放在同一个目录下），
修改：cvsweb.cgi让CGI找到配置文件：
$config = $ENV{'CVSWEB_CONFIG'} || '/path/to/apache/conf/cvsweb.conf';

转到/path/to/apache/conf下并修改cvsweb.conf：

1. 修改CVSROOT路径设置：
   %CVSROOT = (
   'Development' => '/path/to/cvsroot', #<==修改指向本地的CVSROOT
   );
2. 缺省不显示已经删除的文档：
   "hideattic" => "1",#<==缺省不显示已经删除的文档
3. 在配置文件cvsweb.conf中还可以定制页头的描述信息，你可以修改$long_intro成你需要的文字

CVSWEB可不能随便开放给所有用户，因此需要使用WEB用户认证：
先生成 passwd:
/path/to/apache/bin/htpasswd -c cvsweb.passwd user

修改httpd.conf: 增加
<Directory "/path/to/apache/cgi-bin/cvsweb/">
AuthName "CVS Authorization"
AuthType Basic
AuthUserFile /path/to/cvsweb.passwd
require valid-user
</Directory>

CVS TAGS: $Id: cvs_card.html,v 1.5 2003/03/09 08:41:46 chedong Exp $

几个常用的缺省文件：
default.php
<?php
/*
 * Copyright (c) 2002 Company Name.
 * $Header: /home/cvsroot/tech/cvs_card.html,v 1.9 2003/11/09 07:57:11 chedong Exp $
 */

?>
====================================
Default.java: 注意文件头一般注释用 /* 开始 JAVADOC注释用 /** 开始的区别
/*
 * Copyright (c) 2002 MyCompany Name.
 * $Header: /home/cvsroot/tech/cvs_card.html,v 1.9 2003/11/09 07:57:11 chedong Exp $
 */

package com.mycompany;

import java.;

/**
 * comments here
 */
public class Default {
    /**
     * Comments here
     * @param
     * @return
     */
    public toString() {

    }
}
====================================
default.pl:
#!/usr/bin/perl -w
# Copyright (c) 2002 Company Name.
# $Header: /home/cvsroot/tech/cvs_card.html,v 1.9 2003/11/09 07:57:11 chedong Exp $

# file comments here

use strict;

CVS vs VSS

CVS没有文件锁定模式，VSS在check out同时，同时记录了文件被导出者锁定。

CVS的update和commit， VSS是get_lastest_version和check in

对应VSS的check out/undo check out的CVS里是edit和unedit

在CVS中，标记自动更新功能缺省是打开的，这样也带来一个潜在的问题，就是不用-kb方式添加binary文件的话在cvs自动更新时可能会导致文件失效。

$Header: /home/cvsroot/tech/cvs_card.html,v 1.5 2003/03/09 08:41:46 chedong Exp $ $Date: 2003/11/09 07:57:11 $这样的标记在Virsual SourceSafe中称之为Keyword Explaination，缺省是关闭的，需要通过OPITION打开，并指定需要进行源文件关键词扫描的文件类型：*.txt,*.java, *.html...

对于Virsual SourceSafe和CVS都通用的TAG有：
$Header: /home/cvsroot/tech/cvs_card.html,v 1.5 2003/03/09 08:41:46 chedong Exp $
$Author: chedong $
$Date: 2003/11/09 07:57:11 $
$Revision: 1.9 $

我建议尽量使用通用的关键词保证代码在CVS和VSS都能方便的跟踪。

WinCVS

cvs Windows客户端：目前稳定版本为1.2
http://cvsgui.sourceforge.net
ssh Windows客户端
http://www.networksimplicity.com/openssh/

安装好以上2个软件以后：
WinCVS客户端的admin==>preference设置
1 在general选单里
设置CVSROOT： username@192.168.0.123:/home/cvsroot
设置Authorization: 选择SSH server

2 Port选单里
钩上：check for alternate rsh name
并设置ssh.exe的路径，缺省是装在 C:\Program Files\NetworkSimplicity\ssh\ssh.exe

然后就可以使用WinCVS进行cvs操作了，所有操作都会跳出命令行窗口要求你输入服务器端的认证密码。

当然，如果你觉得这样很烦的话，还有一个办法就是生成一个没有密码的公钥/私钥对，并设置CVS使用基于公钥/私钥的SSH认证（在general 选单里）。

可以选择的diff工具：examdiff
下载：
http://www.prestosoft.com/examdiff/examdiff.htm
还是在WinCVS菜单admin==>preference的WinCVS选单里
选上：Externel diff program
并设置diff工具的路径，比如：C:\Program Files\ed16i\ExamDiff.exe
在对文件进行版本diff时，第一次需要将窗口右下角的use externel diff选上。

基于CVSTrac的小组开发环境搭建

这里首先说一下CVS的pserver模式下的用户认证，CVS的用户认证服务是基于inetd中的：
cvspserver stream tcp nowait apache /usr/bin/cvs cvs --allow-root=/home/cvsroot pserver
一般在2401端口（这个端口号很好记：49的平方）

CVS用户数据库是基于CVSROOT/passwd文件，文件格式：
[username]:[crypt_password]:[mapping_system_user]
由于密码都用的是UNIX标准的CRYPT加密，这个passwd文件的格式基本上是apache的htpasswd格式的扩展（比APACHE的 PASSWD文件多一个系统用户映射字段），所以这个文件最简单的方法可以用
apache/bin/htpasswd -b myname mypassword
创建。注意：通过htpasswd创建出来的文件会没有映射系统用户的字段
例如：
new:geBvosup/zKl2
setup:aISQuNAAoY3qw
test:hwEpz/BX.rEDU

映射系统用户的目的在于：你可以创建一个专门的CVS服务帐号，比如用apache的运行用户apache，并将/home/cvsroot目录下的所有权限赋予这个用户，然后在passwd文件里创建不同的开发用户帐号，但开发用户帐号最后的文件读写权限都映射为apache用户，在SSH模式下多个系统开发用户需要在同一个组中才可以相互读写CVS库中的文件。

进一步的，你可以将用户分别映射到apache这个系统用户上。
new:geBvosup/zKl2:apache
setup:aISQuNAAoY3qw:apache
test:hwEpz/BX.rEDU:apache

CVSTrac很好的解决了CVSROOT/passwd的管理问题，而且包含了BUG跟踪报告系统和集成WIKIWIKI交流功能等，使用的 CGI方式的安装，并且基于GNU Public License：

在inetd里加入cvspserver服务：
cvspserver stream tcp nowait apache /usr/bin/cvs cvs --allow-root=/home/cvsroot pserver

xietd的配置文件：%cat cvspserver
service cvspserver
{
disable = no
socket_type = stream
wait = no
user = apache
server = /usr/bin/cvs
server_args = -f --allow-root=/home/cvsroot pserver
log_on_failure += USERID
}

注意：这里的用户设置成apache目的是和/home/cvsroot的所有用户一致，并且必须让这个这个用户对/home/cvsroot/下的 CVSROOT/passwd和cvstrac初始化生成的myproj.db有读取权限。

安装过程

1. 下载：可以从http://www.cvstrac.org 下载
   我用的是已经在Linux上编译好的应用程序包：cvstrac-1.1.2.bin.gz，
   %gzip -d cvstrac-1.1.2.bin.gz
   %chmod +x cvstrac-1.1.2.bin
   #mv cvstarc-1.1.1.bin /usr/bin/cvstrac
   如果是从源代码编译：
   从 http://www.sqlite.org/download.html 下载SQLITE的rpm包：
   rpm -i sqlite-devel-2.8.6-1.i386.rpm
   从 ftp://ftp.cvstrac.org/cvstrac/ 下载软件包
   解包，假设解包到/home/chedong/cvstrac-1.1.2下，并规划将cvstrac安装到/usr/local/bin目录下， cd /home/chedong/cvstrac-1.1.2 编辑linux-gcc.mk:
   修改：
   SRCDIR = /home/chedong/cvstrac-1.1.2
   INSTALLDIR = /usr/local/bin
   然后
   mv linux-gcc.mk Makefile
   make
   #make install
   
   
2. 初始化cvstrac数据库：假设数据库名是 myproj
   在已经装好的CVS服务器上（CVS库这时候应该已经是初始化好了，比如：cvs init初始化在/home/cvsroot里），运行一下
   %cvstrac init /home/cvsroot myproj
   运行后，/home/cvsroot里会有一个的myproj.db库，使用CVSTRAC服务，/home/cvsroot/myproj.db /home/cvsroot/CVSROOT/readers /home/cvsroot/CVSROOT/writers /home/cvsroot/CVSROOT/passwd这几个文件对于web服务的运行用户应该是可写的，在RedHat8上，缺省就有一个叫 apache用户和一个apache组，所以在httpd.conf文件中设置了用apache用户运行web服务：
   User apache
   Group apache，
   然后设置属于apache用户和apache组
   #chown -R apache:apache /home/cvsroot
   -rw-r--r-- 1 apache apache 55296 Jan 5 19:40 myproj.db
   drwxrwxr-x 3 apache apache 4096 Oct 24 13:04 CVSROOT/
   drwxrwxr-x 2 apache apache 4096 Aug 30 19:47 some_proj/
   此外还在/home/cvsroot/CVSROOT中设置了：
   chmod 664 readers writers passwd
   
3. 在apche/cgi-bin目录中创建脚本cvstrac:
   #!/bin/sh
   /usr/bin/cvstrac cgi /home/cvsroot
   设置脚本可执行：
   chmod +x /home/apache/cgi-bin/cvstrac
   
4. 从 http://cvs.server.address/cgi-bin/cvstrac/myproj 进入管理界面
   缺省登录名：setup 密码 setup
   对于一般用户可以从：
   http://cvs.server.address/cgi-bin/cvstrac/myproj
5. 在setup中重新设置了CVSROOT的路径后，/home/cvsroot
   如果是初次使用需要在/home/cvsroot/CVSROOT下创建passwd, readers, writers文件
   touch passwd readers writers
   然后设置属于apache用户，
   chown apache.apache passwd readers writers
   这样使用setup用户创建新用户后会同步更新CVSROOT/passwd下的帐号
   

修改登录密码，进行BUG报告等，
更多使用细节可以在使用中慢慢了解。

对于前面提到的WinCVS在perference里设置：
CVSROOT栏输入：username@ip.address.of.cvs:/home/cvsroot
Authenitication选择：use passwd file on server side
就可以了从服务器上进行CVS操作了。

CVS的用户权限管理

CVS的权限管理分2种策略：

• 基于系统文件权限的系统用户管理：适合多个在Linux上使用系统帐号的开发人员进行开发。
• 基于CVSROOT/passwd的虚拟用户管理：适合多个在Windows平台上的开发人员将帐号映射成系统帐号使用。

Linux上通过ssh连接CVS服务器的多个开发人员：通过都属于apache组实现文件的共享读写
开发人员有开发服务器上的系统帐号：sysuser1 sysuser2，设置让他们都属于apache组，因为通过cvs新导入的项目都是对组开放的：664权限的，这样无论那个系统用户导入的项目文件，只要文件的组宿主是apache，所有其他同组系统开发用户就都可以读写；基于ssh远程认证的也是一样。

   apache(system group)
/            |           \
sysuser1   sysuser2     sysuser3

Windows上通过cvspserver连接CVS服务器的多个开发人员：通过在passwd文件种映射成 apache用户实现文件的共享读写
他们的帐号通过CVSROOT/passwd和readers writers这几个文件管理；通过cvstrac设置所有虚拟用户都映射到apache用户上即可。

   apache(system user)
/            |            \
windev1     windev2      windev3             

利用cvs + (WinCVS/cvsweb/cvstrac)，构成了一个相对完善的跨平台工作组开发版本控制环境。

相关资源：

CVS HOME：
http://www.cvshome.org

CVS FAQ：
http://www.loria.fr/~molli/cvs-index.html

相关网站:
http://directory.google.com/Top/Computers/Software/Configuration_Management/Tools/Concurrent_Versions_System/

CVS--并行版本系统
http://www.soforge.com/cvsdoc/zh_CN/book1.html

CVS 免费书:
http://cvsbook.red-bean.com/

CVS 命令的速查卡片：
http://www.refcards.com/about/cvs.html

WinCVS:
http://cvsgui.sourceforge.net/

CVSTrac: A Web-Based Bug And Patch-Set Tracking System For CVS
http://www.cvstrac.org

StatCVS：基于CVS的代码统计工具：按代码量，按开发者的统计表等
http://sourceforge.net/projects/statcvs

多年来，分析者总是利用情节或经历来描述用户和软件系统的交互方式，从而获取需求（McGraw and Harbison 1997）。Ivar Jacobson（1992）把这种看法系统地阐述成用例（用例）的方法进行需求获取和建模。虽然用例来源于面向对象的开发环境，但是它也能应用在具有许多开发方法的项目中，因为用户并不关心你是怎样开发你的软件。而最重要的，用例的观点和思维过程带给需求开发的改变比起是否画正式的用例图显得更为重要。注意用户要利用系统做什么远远强于询问用户希望系统为他们做什么这一传统方法。 用例的重要功能是用画用例图的功能来鉴别和划分系统功能。它把系统分成角色（actor）和用例（用例）。角色(actor)表示系统用户能扮演的角色（role）。这些用户可能是人，可能是其他的计算机一些硬件或者甚至是其它软件系统，唯一的标准是它们必须要在被划分进用例的系统部分以外。它们必须能刺激系统部分并接收返回。用例描述了当角色给系统特定的刺激时系统的活动。这些活动被文本描述。它描述了触发用例的刺激的本质，输入和输出到其他活动者，和转换输入到输出的活动。用例文本通常也描述每一个活动在特殊的活动线时可能的错误和系统应采取的补救措施。 这样说可能会非常复杂，其实一个用例描述了系统和一个角色（actor）的交互顺序。用例被定义成系统执行的一系列动作，动作执行的结果能被指定角色察觉到。用例可以:
　　用例捕获某些用户可见的需求，实现一个具体的用户目标。
　　用例由角色激活，并提供确切的值给角色。
　　用例可大可小，但它必须是对一个具体的用户目标实现的完整描述。在UML中，用例表示为一个椭圆。
　　角色是指用户在系统中所扮演的角色。其图形化的表示是一个小人。在某些组织中很可能有许多角色实例（例如有很多个销售员），但就该系统而言，他们均起着同一种作用，扮演着相同的角色，所以用一个角色表示。一个用户也可以扮演多种角色。例如，一个高级营销人员既可以是贸易经理，也可以是普通的营销人员；一个营销人员也可以是售货员。在处理角色时，应考虑其作用，而不是人或工作名称，这一点是很重要的。
　　我们使用不带箭头的线段将角色与用例连接到一起，表示两者之间交换信息，称之为通信联系。角色触发用例，并与用例进行信息交换。单个角色可与多个用例联系；反过来，一个用例可与多个角色联系。对同一个用例而言，不同角色有着不同的作用：他们可以从用例中取值，也可以参与到用例中。需要注意的是角色在用例图中是用类似人的图形来表示，尽管执行的，但角色未必是人。例如，角色也可以是一个外界系统，该外界系统可能需要从当前系统中获取信息，与当前系统有进行交互。
　　一个用例可能包括完成某项任务的许多逻辑相关任务和交互顺序。因此，一个用例是相关的用法说明的集合，并且一个说明（scenario）是用例的实例。这种关系就像是类和对象的关系。在用例中，一个说明被视为事件的普通过程(normal course)，也叫作主过程，基本过程，普通流，或“满意之路” (happy path)。在描述普通过程时列出执行者和系统之间相互交互或对话的顺序。当这种交互结束时，执行者也达到了预期的目的。
　　在用例中的其它说明可以描述为可选过程(alternative coruse)。可选过程也可促进成功地完成任务，但它们代表了任务的细节或用于完成任务的途径的变化部分。在交互序列中，普通过程可以在一些决策点上分解成可选过程，然后再重新汇成一个普通过程。
角色类和角色实例
　　软件产品最终是给一些用户来使用的，而用户之间的差异是非常大的。造成差异的原因包括了对计算机的认知程度的不同，使用习惯的不同，在软件目标组织中所处的地位不同，地理位置不同，业务熟练程度不同。
　　不同的用户都有自己一系列的功能需求和非功能需求。对电脑熟练程度不同的人可能就会有不同的要求，熟练程度低的用户可能希望有一个友好的界面，熟练程度高的用户可能更希望有快捷键或宏的操作以提高工作效率。考虑到用户的差异性，将用户分类并研究用户类的行为特征是非常有必要的。所以在做具体的需求之前，先将用户分局行为和特点进行分类，对于研究、收集用户的需求是非常有帮助的。
　　可以利用一个简单的表格列出一些原始的分类，然后不断的完善这个表格。确认你的分类之间没有交集。并充分描述用户分类的行为，目的，要求等。在企业分析中，比较常见的分类可能包括，供应商，客户，部门等。
　　就像C++中的类和对象一样，我们把分析出的用户分类称为“角色类”，把实际的用户称为“角色实例”。在得到用户分类之后，最重要的就是要选出用户代表，用户代表不仅仅是在需求阶段中参与项目，还必须对项目的全过程负责。用户代表能够代表用户分类的需求。抓住用户代表的需求就大致把握住了用户类的需求。当然，需求分析还是需要在用户中做大规模的调查的，只是要把重点放在用户代表上。
　　确保和用户直接进行沟通！大家有没有玩过传话的游戏，可能看过。一群人排成一列，一句话从排头挨个向后传，到最后，那句话已经是面目全非了。所以，一定要保证项目组能够直接和用户接触。 对于和用户直接沟通这一点，一般的针对特定企业的应用系统当然是不成问题，可是如果是开发行业软件，和用户直接沟通就成为一件几乎是不可能的事情。在这种情况下，一般有几种解决的办法：
　　做大规模的市场调查，针对你的目标市场做市场调查，并根据统计学的理论建立你的数学模型。这部分的工作效果最好，其性质有些象一些游戏公司会发布一些Demo版的游戏。可是对于一般的企业来说，这项工作费时费力，高昂的成本往往使大家知难而退。我的意见是，方法是非常好的，但是可以采用折衷的办法，例如选取有代表性的企业，为特定企业制作一个较小的版本并收集反馈意见等。这涉及到很多市场营销的内容，并不是我的专业所长，这里就不多弄斧了。 聘请行业专家，一个行业专家往往可以在项目需求方面发挥极为重要的作用。一个行业专家往往都有大量的行业经验和行业的人际关系网络。在产品的设计方面，这个行业专家提供很多宝贵的意见。在目前很多的软件的开发过程中都采用了这种方式。行业专家有两种：一种是在这个行业中有很深的资历，但是对软件技术并不熟悉；第二种是开发过同类软件的软件专家，这种人在开发同类软件过程中已经积累了大量的项目经验，并且具有软件开发的知识。这种方式是获取需求的最好的方式。 分析对比同类软件，微软在开发Office、Visual Studio的时候，也是参照了Lotus和Borland的成熟产品。这种方式的特点在于成本很低，比较适合和其他的方式配合使用。但是，要注意自己有没有触犯专利法。
需求的冲突
　　有的时候，虽然已经将用户分类并选出了用户代表。但是需求的来源众多，往往会发生需求之间自相矛盾的事情。需求从四面八方收集来后，人们难以解决冲突，澄清模糊之处以及协调不一致之处。某些人还要对不可避免要发生的范围问题单独作出决定。在项目的早期阶段，你必须决定谁是需求问题的决策者。如果不清楚谁有权并且有责任来作出决策，或者授权的个人不愿意或不能作出决策，那么决策者的角色将自然而然地落在开发者身上。这是一个非常糟糕的选择，因为开发者通常没有足够多的信息和观点来作出业务上的决策。
　　在软件项目中，谁将对需求作出决策的问题并没有统一的正确答案。分析员有时听从呼声高的或来自最高层人物的最大的需求。即便使用用户代表这一手段，必须解决来自不同用户类的相冲突的需求。通常，应尽可能由处于公司底层的人作出决策，因为他们与问题密切相关，并能得到关于这些问题的广泛信息。
　　如果不同的用户类有不一致的需求，那么必须决策出满足哪一类用户的需求更为重要。了解可能使用产品的客户种类的信息和他们的用法与产品的业务目标的关系如何，将有助于你决定哪一个用户类所占份额最大。
　　当开发者想象中的产品与客户需求冲突时，通常应该由客户作出决策。然而，不要陷到“客户总是对的”的陷阱中去，对他们百依百顺。现实中，客户并不总是对的。客户总是持有自己的观点，开发者必须理解并尊重这一观点。
用例
　　在具体的需求过程中，有大的用例（业务用例），也有小的用例。主要是由于用例的范围决定的。用例像是一个黑盒，它没有包括任何和实现有关或是内部的一些信息。它很容易就被用户（也包括开发者）所理解（简单的谓词短语）。如果用例不足以表达足够的信息来支持系统的开发，就有必要把用例黑盒打开，审视其内部的结构，找出黑盒内部的Actor和用例。就这样通过不断的打开黑盒，分析黑盒，再打开新的黑盒。直到整个系统可以被清晰的了解为止。

　　为什么要采用这种分析方法呢？计算机系统除了在与外界系统、人员有一系列的交互，在系统内部也往往存在着复杂的交互。因此，在系统建模时，除了描述系统与外界的交互，同时还要描述系统内部的交互。传统的MIS系统中，系统与外界的交互较多。典型的，如ATM取款机：存在着大量的用户与ATM，ATM与其它系统的交互。而电信领域的系统，与外界的交互较少。例如，系统的输入可能仅仅是从交换机上采集信息，然后由系统进行处理。系统的复杂逻辑包含在系统内部处理的流程上，而非与外部系统的交互。建模主要任务是表达系统内部的交互。
　　用例图适于表达交互，之所以上面使用了电信系统，是因为用例最早来自于Ericsson的交换机系统。当时，还是Ericsson雇员的Jacobson初步建立了用例图的概念，并于1994年提出了OOSE方法，其最大特点是面向用例（Use-Case），并在用例的描述中引入了外部角色的概念。用例的概念是精确描述需求的重要武器，比较适合支持商业工程和需求分析。随着用例的发展，用例被大量的 用于对功能进行描述。每个用例代表了系统与外部ACTOR的交互。可以采取顺序图来表达用例的具体操作程序。ACTOR用于确定系统的边界。
　　ACTOR、用例可以从不同的层次来描述信息。采用该原则的原因有：
　　1. 需求并不是在项目一开始就很明确，往往是随着项目的推进，逐渐细化。
　　2. 人的认知往往具有层次的特性。从粗到细、从一般到特殊。采用不同的层次来描述，适于认知的过程。 使用用例开发系统的一般过程
　　在开发过程的初始阶段，可以根据具体的项目特点，制订开发各个视图之间的关联原则，指导规范。在开发的过程中，视图的组织原则应不断进行维护、更新。
　　识别ACTOR来识别系统与外界交互的实体。ACTOR具有特定领域的特征，例如：交换机（采集系统）、97信息系统等。在系统层次的ACTOR确定了系统的边界。
　　识别用例。同ACTOR一样，用例具有不同层次。对较为概括的USECASE，需要细化。注：系统开发需要一定的规则来确定，如何来分解用例；可能基于原有系统的经验，或是参考现有资料。
　　当用例细化到可以被理解的层次。需要基于用例进行下一步的开发。如前面提到的，用例主要用来描述交互。因此，存在交互的实体和交互的细节。交互的实体采用类图来描述；而交互的细节，采用顺序图来描述。
　　当系统复杂到一定层次时，类图和顺序图可能不能足以描述其复杂程度。在该情况下，需要使用状态图来辅助阐述。状态图和顺序图之间使用事件联结在一起。它们之间的一致性问题，目前UML和ROSE没有提供解决方案。相对折衷的方法是使用事件的命名规范强制一致性。
　　可以说，之前说的所有的东西都是为了能够导出用例在需求中的作用。用例是从用户的角度看待系统，而不是基于程序员的角度。这样的话，用例驱动的系统能够真正做到以用户为中心，用户的任何需求都能够在系统开发链中完整的体现。用户和程序员间通过用例沟通，避免了牛头马嘴的尴尬局面。 从前，系统开发者总是通过情节来获取需求，是问用户希望系统为他做什么。在Jacobson发明了用例的概念之后，需求获取就变成问用户要利用系统做什么。这是立场不同导致的结果。用户通常并不关心系统是如何实现的（也有少数可爱的技术狂是例外）。对他们来说，更重要的是要达到他的目的。相反的，大部分的程序员的工作习惯就是考虑计算机应该如何实现用户的要求。所幸的是，用例方法能够调和双方的矛盾，因为虽然用例是来源于用户，服务于用户，但是它同样可以用于开发的流程。当系统的开发过程都是基于用例的，用用例获取需求，用用例设计，用用例编码，用用例测试的时候。这个开发过程就是用例驱动的。 用例和用例文档
　　《软件需求》一书中提到了几种方法来确定用例：
　　首先明确执行者和他们的角色，然后确定业务过程，在这一过程中每一个参与者都在为确定用例而努力。
　　确定系统所能反映的外部事件，然后把这些事件与参与的执行者和特定的用例联系起来。
　　以特定的说明形式表达业务过程或日常行为，从这些说明中获得用例，并确定参与到用例中的执行者，有可能从现在的功能需求说明中获得用例。如果有些需求与用例不一致，就应考虑是否真的需要它们。
　　用例代表了用户的需求，在你的系统中，应该直接从不同用户类的代表或至少应从代理那里收集需求。用例为表达用户需求提供了一种方法，而这一方法必须与系统的业务需求相一致。分析者和用户必须检查每一个用例，在把它们纳入需求之前决定其是否在项目所定义的范围内。基于“用例”方法进行需求获取的目的在于：描述用户需要使用系统完成的所有任务。在理论上，用例的结果集将包括所有合理的系统功能。在现实中，你不可能获得完全包容，但是比起我所知道的其它获取方法，基于用例的方法可以为你带来更好的效果。 当使用用例进行需求获取时，应避免受不成熟的细节的影响。在对切合的客户任务取得共识之前，用户能很容易地在一个报表或对话框中列出每一项的精确设计。如果这些细节都作为需求记录下来，他们会给随后的设计过程带来不必要的限制。你可能要周期性地检查需求获取，以确保用户参与者将注意力集中在与今天所讨论的话题适合的抽象层上。向他们保证在开发过程中，将会详尽阐述他们的需求。在一个逐次详细描述过程中，重复地详述需求，以确定用户目标和任务，并作为用例。然后，把任务描述成功能需求，这些功能需求可以使用户完成其任务，也可以把它们描述成非功能需求，这些非功能需求描述了系统的限制和用户对质量的期望。虽然最初的屏幕构思有助于描述你对需求的理解，但是你必须细化用户界面设计。 建立用例文档。在每一次的需求获取之后，都会生成很多未整理的需求，你必须将它们组织成用例文档。使用诸如模板的技术能够提高你的速度和需求的复用性。一个用例文档可以使用表格来组织，主要的要素包括了用例标识号、用例名称、父用例标志号、创建者、创建时间、审核者、修订记录、角色、说明、先决条件、请求结果、优先级、普通过程、可选过程、例外、非功能需求、假设、注释和问题。 虽然列举出了这么多的属性，但是实际中使用的属性这要看你的团体而定，看项目的大小而定。把大量的时间花在用例的描述上是没有意义的。用户需要的是一个软件系统，并不是一大堆的用例说明。

　　为便于理解和记忆，先从一些概念入手，所有特殊字符或字符组合有一个总表在后面，最后一些例子供理解相应的概念。

正则表达式

普通字符

非打印字符

特殊字符

　　构造正则表达式的方法和创建数学表达式的方法一样。也就是用多种元字符与操作符将小的表达式结合在一起来创建更大的表达式。正则表达式的组件可以是单个的字符、字符集合、字符范围、字符间的选择或者所有这些组件的任意组合。

限定符

定位符

选择

后向引用

各种操作符的运算优先级

全部符号解释

部分例子

参考文献：
正则表达式
http://www.soulogic.com/code/doc/RegularExpressions/

　　简单的说，正则表达式是一种可以用于模式匹配和替换的强有力的工具。我们可以在几乎所有的基于UNIX系统的工具中找到正则表达式的身影，例如，vi编辑器，Perl或PHP脚本语言，以及awk或sed shell程序等。此外，象JavaScript这种客户端的脚本语言也提供了对正则表达式的支持。由此可见，正则表达式已经超出了某种语言或某个系统的局限，成为人们广为接受的概念和功能。

　　正则表达式可以让用户通过使用一系列的特殊字符构建匹配模式，然后把匹配模式与数据文件、程序输入以及WEB页面的表单输入等目标对象进行比较，根据比较对象中是否包含匹配模式，执行相应的程序。

　　举例来说，正则表达式的一个最为普遍的应用就是用于验证用户在线输入的邮件地址的格式是否正确。如果通过正则表达式验证用户邮件地址的格式正确，用户所填写的表单信息将会被正常处理；反之，如果用户输入的邮件地址与正则表达的模式不匹配，将会弹出提示信息，要求用户重新输入正确的邮件地址。由此可见正则表达式在WEB应用的逻辑判断中具有举足轻重的作用。

基本语法

　　在对正则表达式的功能和作用有了初步的了解之后，我们就来具体看一下正则表达式的语法格式。

　　正则表达式的形式一般如下：

　　/love/

　　其中位于“/”定界符之间的部分就是将要在目标对象中进行匹配的模式。用户只要把希望查找匹配对象的模式内容放入“/”定界符之间即可。为了能够使用户更加灵活的定制模式内容，正则表达式提供了专门的“元字符”。所谓元字符就是指那些在正则表达式中具有特殊意义的专用字符，可以用来规定其前导字符（即位于元字符前面的字符）在目标对象中的出现模式。

　　较为常用的元字符包括： “+”， “*”，以及 “?”。其中，“+”元字符规定其前导字符必须在目标对象中连续出现一次或多次，“*”元字符规定其前导字符必须在目标对象中出现零次或连续多次，而“?”元字符规定其前导对象必须在目标对象中连续出现零次或一次。

　　下面，就让我们来看一下正则表达式元字符的具体应用。

　　/fo+/

　　因为上述正则表达式中包含“+”元字符，表示可以与目标对象中的 “fool”, “fo”, 或者 “football”等在字母f后面连续出现一个或多个字母o的字符串相匹配。

　　/eg*/

　　因为上述正则表达式中包含“*”元字符，表示可以与目标对象中的 “easy”, “ego”, 或者 “egg”等在字母e后面连续出现零个或多个字母g的字符串相匹配。

　　/Wil?/

　　因为上述正则表达式中包含“？”元字符，表示可以与目标对象中的 “Will”, 或者 “Wilson”,等在字母i后面连续出现零个或一个字母l的字符串相匹配。

　　除了元字符之外，用户还可以精确指定模式在匹配对象中出现的频率。例如，

　　/jim{2,6}/

　　上述正则表达式规定字符m可以在匹配对象中连续出现2-6次，因此，上述正则表达式可以同jimmy或jimmmmmy等字符串相匹配。

　　在对如何使用正则表达式有了初步了解之后，我们来看一下其它几个重要的元字符的使用方式。

　　s：用于匹配单个空格符，包括tab键和换行符；

　　S：用于匹配除单个空格符之外的所有字符；

　　d：用于匹配从0到9的数字；

　　w：用于匹配字母，数字或下划线字符；

　　W：用于匹配所有与w不匹配的字符；

　　. ：用于匹配除换行符之外的所有字符。

　　（说明：我们可以把s和S以及w和W看作互为逆运算）
下面，我们就通过实例看一下如何在正则表达式中使用上述元字符。

　　/s+/

　　上述正则表达式可以用于匹配目标对象中的一个或多个空格字符。

　　/d000/

　　如果我们手中有一份复杂的财务报表，那么我们可以通过上述正则表达式轻而易举的查找到所有总额达千元的款项。

　　除了我们以上所介绍的元字符之外，正则表达式中还具有另外一种较为独特的专用字符，即定位符。定位符用于规定匹配模式在目标对象中的出现位置。

　　较为常用的定位符包括： “^”, “$”, “” 以及 “B”。其中，“^”定位符规定匹配模式必须出现在目标字符串的开头，“$”定位符规定匹配模式必须出现在目标对象的结尾，定位符规定匹配模式必须出现在目标字符串的开头或结尾的两个边界之一，而“B”定位符则规定匹配对象必须位于目标字符串的开头和结尾两个边界之内，即匹配对象既不能作为目标字符串的开头，也不能作为目标字符串的结尾。同样，我们也可以把“^”和“$”以及“”和“B”看作是互为逆运算的两组定位符。举例来说：

　　/^hell/

　　因为上述正则表达式中包含“^”定位符，所以可以与目标对象中以 “hell”, “hello”或 “hellhound”开头的字符串相匹配。

　　/ar$/

　　因为上述正则表达式中包含“$”定位符，所以可以与目标对象中以 “car”, “bar”或 “ar” 结尾的字符串相匹配。

　　/bom/

　　因为上述正则表达式模式以“”定位符开头，所以可以与目标对象中以 “bomb”, 或 “bom”开头的字符串相匹配。

　　/man/

　　因为上述正则表达式模式以“”定位符结尾，所以可以与目标对象中以 “human”, “woman”或 “man”结尾的字符串相匹配。

　　为了能够方便用户更加灵活的设定匹配模式，正则表达式允许使用者在匹配模式中指定某一个范围而不局限于具体的字符。例如：

　　/[A-Z]/

　　上述正则表达式将会与从A到Z范围内任何一个大写字母相匹配。

　　/[a-z]/

　　上述正则表达式将会与从a到z范围内任何一个小写字母相匹配。

　　/[0-9]/

　　上述正则表达式将会与从0到9范围内任何一个数字相匹配。

　　/([a-z][A-Z][0-9])+/

　　上述正则表达式将会与任何由字母和数字组成的字符串，如 “aB0” 等相匹配。这里需要提醒用户注意的一点就是可以在正则表达式中使用 “()” 把字符串组合在一起。“()”符号包含的内容必须同时出现在目标对象中。因此，上述正则表达式将无法与诸如 “abc”等的字符串匹配，因为“abc”中的最后一个字符为字母而非数字。

　　如果我们希望在正则表达式中实现类似编程逻辑中的“或”运算，在多个不同的模式中任选一个进行匹配的话，可以使用管道符 “|”。例如：

　　/to|too|2/

　　上述正则表达式将会与目标对象中的 “to”, “too”, 或 “2” 相匹配。

　　正则表达式中还有一个较为常用的运算符，即否定符 “[^]”。与我们前文所介绍的定位符 “^” 不同，否定符 “[^]”规定目标对象中不能存在模式中所规定的字符串。例如：

　　/[^A-C]/

　　上述字符串将会与目标对象中除A，B，和C之外的任何字符相匹配。一般来说，当“^”出现在 “[]”内时就被视做否定运算符；而当“^”位于“[]”之外，或没有“[]”时，则应当被视做定位符。

　　最后，当用户需要在正则表达式的模式中加入元字符，并查找其匹配对象时，可以使用转义符“”。例如：

　　/Th*/

　　上述正则表达式将会与目标对象中的“Th*”而非“The”等相匹配。
使用实例

　　在对正则表达式有了较为全面的了解之后，我们就来看一下如何在Perl，PHP，以及JavaScript中使用正则表达式。

　　通常，Perl中正则表达式的使用格式如下：

　　operator / regular-expression / string-to-replace / modifiers

　　运算符一项可以是m或s，分别代表匹配运算和替换运算。

　　其中，正则表达式一项是将要进行匹配或替换操作的模式，可以由任意字符，元字符，或定位符等组成。替换字符串一项是使用s运算符时，对查找到的模式匹配对象进行替换的字符串。最后的参数项用来控制不同的匹配或替换方式。例如：

　　s/geed/good/

　　将会在目标对象中查找第一个出现的geed字串，并将其替换为good。如果我们希望在目标对象的全局范围内执行多次查找—替换操作的话，可以使用参数 “g”，即s/love/lust/g。

　　此外，如果我们不需要限制匹配的大小写形式的话，可以使用参数 “i ”。例如，

　　m/JewEL/i

　　上述正则表达式将会与目标对象中的jewel，Jewel，或JEWEL相匹配。

　　在Perl中，使用专门的运算符“=~”指定正则表达式的匹配对象。例如：

　　$flag =~ s/abc/ABC/

　　上述正则表达式将会把变量$flag中的字串abc替换为ABC。

　　下面，我们就在Perl程序中加入正则表达式，验证用户邮件地址格式的有效性。代码如下：

　　#!/usr/bin/perl
　　# get input
　　print “What's your email address? ”;
　　$email = <>
　　chomp($email);
　　# match and display result
　　if($email =~ /^([a-zA-Z0-9_-])+@([a-zA-Z0-9_-])+(.[a-zA-Z0-9_-])+/)
　　{
　　print(“Your email address is correct! ”);
　　}
　　else
　　　{
　　　　print(“Please try again! ”);
　　　}
如果用户更偏爱PHP的话，可以使用ereg()函数进行模式匹配操作。ereg()函数的使用格式如下：
　　 ereg(pattern, string)

　　其中，pattern代表正则表达式的模式，而string则是执行查找替换操作的目标对象。同样是验证邮件地址，使用PHP编写的程序代码如下：

　　　　 if (ereg(“^([a-zA-Z0-9_-])+@([a-zA-Z0-9_-])+(.[a-zA-Z0-9_-])+”,$email))
　　　 { echo “Your email address is correct!”;}
　　 else
　　　 { echo “Please try again!”;}
　　 ?>
　　最后，我们在来看一下JavaScript。JavaScript 1.2中带有一个功能强大的RegExp()对象，可以用来进行正则表达式的匹配操作。其中的test()方法可以检验目标对象中是否包含匹配模式，并相应的返回true或false。

　　我们可以使用JavaScript编写以下脚本，验证用户输入的邮件地址的有效性。

　　
　　
　　　 < language="Javascript1.2">
　　　　
　　　
　　　
　　
　　

前言

    如果数据库系统（ database systems）像受人尊敬的智者讲述的条理清晰的故事，那么工作流（workflow）就像一群乳臭未干的小子在大谈各自的“哲理”。之所以这样讲，我是想指出，工作流系统 （workflow management systems）还处于技术发展曲线（ technology hype curve）上的初级阶段。在这个领域我们将面临一个激动人心的阶段。 为了描述这一点，可以将工作流和关系数据库系统（RDBMS）做一个对比。当在软件开发团队中谈论RDBMS时，大部分人会有一个清晰的概念，在你和他们交流的时候，人们会通过轻微的点头表示认可或理解你所说的。可当使用工作流术语讨论工作流时，他们会摇头表示不同意，因为每个人对工作流术语都有不同的理解。

Figure 1: Workflow vs. RDBMS positioned in the hype-curve

    导致形成这种状况的原因之一，是在工作流中使用了过多的概念。在这个领域中的大量规范和工具没有一个是相似的。当然，它们相互之间有重叠并且会相互参考引证。
    在介绍工作流时有一个话题必须包括，那就是工作流和业务流程管理（BPM）的关系。术语“工作流”通常描述人与计算机系统的一系列相关交互。在开发人员中，工作流经常被提及。有时，工作流的意思是指一些不同的UI界面。业务流程管理的范围比较广，相比之下工作流多半局限于技术领域。业务流程管理还从管理人员的角度涉及了非技术问题，比如分析、组织的效率。

    在本文中，我首先解释什么是工作流管理系统，然后介绍业务流程管理的优点。接下来描述一下为什么工作流市场乍看起来如此混乱。本文给出的主要结论是：选择工作流系统是想用工作流系统的公司，将要面对的最困难的事情。为此，本文的核心部分描述了一个流程定义（process definition）的四个层次，为你选择工作流提供一个基础。本文还用中立的语言描述了工作流和BPM的通用概念。最后，给出了一些规范和工具的指导性描述。

什么是工作流管理系统（WFMS）

定义

    工作流系统是以规格化的流程描述作为输入的软件组件,它维护流程的运行状态,并在人和应用之间分派活动。

    为了后面的描述，我们先定义一些基本的术语：流程定义（process definition）和流程实例（process instance）. 一个流程定义是一个业务流程或过程的规格化描述。一个流程实例是流程定义的一个运行实体。 都目前为止，概念还比较清晰是不是？但当再深入一步时，我们就要小心使用文字了。如何阐述流程中的步骤，现在还没有一个统一的方式。这是各种工作流规范和工具之间主要的分歧。

    工作流系统另一个重要的职责是维护每一个流程运行的上下文信息。 流程上下文变量（process context variable） ，或简称变量，是与流程实例相关的变量。如，休假申请的开始日期、数据库中一条记录的键值、文档管理系统中一篇文档的索引等。通常在流程定义中声明这些变量，然后在流程实例生成时，这些流程变量被实例化。所有成熟的工作流管理系统都支持定制的变量类型。

目标领域（Target usage）

    使用工作流管理系统的目的之一是作为企业应用系统集成（EAI）的平台。在当前大部分企业级IT架构中，各种各样的异构（heterogeneous）应用和数据库运行在企业内网中。在这些系统被应用到组织时，都有一个清晰的目标。例如，客户管理、文档管理、供应链、订单、支付、资源计划等等。让我们称这些系统为专门应用（ dedicated applications）。每一个专门应用都包含它们所支持业务流程的领域知识。这些专门应用中的自动化流程，被拼装到企业中更大的非自动化流程中。每当一个这样的专门应用安装并投入使用，都会带来涉及其他多个应用的新功能需求。企业应用系统集成（EAI）就是通过使用多个专门应用满足软件新需求的方法。有时，这只需要在两个应用之间提供数据通讯的通道。专门应用将很多业务流程硬编码在软件中。可以这么说，在你购买专门应用时，你是购买了一组固定的自动化业务流程。而工作流管理系统是不必事先知道问题域的相关信息的。工作流系统将业务流程描述作为输入并管理流程实例的执行，这使得它比专门应用更灵活（当然你也要花精力编写业务流程的规格化描述）。这就是为什么说工作流系统和专门系统是相互补充的。工作流系统可以用来管理全局的业务流程。如果专门应用支持你所需要的业务流程，那么使用专门应用。在此讨论的工作流系统的第一种使用方式就是：结合所有的专门应用，使用工作流系统构建一个EAI平台。

    工作流系统能够发挥很大价值的第二个使用方式是：协助涉及多人相关任务工作流软件的开发。为了达到这个目的，大部分工作流系统都有一个方便的机制，来生成执行任务的表单。对于专注于ISO 或者CMM认证的组织，采用这种方式使用工作流系统能够显著提高生产率。 不用将过程用文字的形式写在纸上，工作流系统使你通过流程定义建模实现过程的自动化（如使用基于Web的应用）。

    工作流系统的第三种使用方式是：将工作流引擎嵌入到其他应用中。在前面我们谈到，专门应用将指定问题域相关的业务流程固化在软件中。开发专门应用的公司也可以将工作流引擎嵌入到他们的软件中。在这里，工作流引擎只是作为一个软件组件，对于应用的最终用户是不可见的。将工作流引擎嵌入到应用中的主要原因是为了重用（不重复发明轮子）和应用软件的可维护性。

The case for workflow

    对于引入工作流的组织，能够在软件开发和业务两个层次受益。

方便开发

    工作流管理系统能够简化企业级软件开发甚至维护。

• 降低开发风险 - 通过使用状态和动作这样的术语，业务分析师和开发人员使用同一种语言交谈。这样开发人员就不必将用户需求转化成软件设计了。
• 实现的集中统一 -业务流程经常变化，使用工作流系统的最大好处是：业务流程的实现代码，不再是散落在各种各样的系统中 。
• 加快应用开发 - 你的软件不用再关注流程的参与者，开发起来更快，代码更容易维护。

业务流程管理 (BPM)

    在自动化业务流程之前，分析并将它们规格化是一件艰苦但会有很好回报的工作。e-workflow.org对于分析流程能够带了的益处有不错的阐述：

• 提高效率 - 许多流程在自动化过程中会去除一些不必要的步骤
• 较好的流程控制 - 通过标准的工作方法和跟踪审计，提高了业务流程的管理
• 改进客户服务 - 因为流程的一致性，提高了对客户响应的可预见性
• 灵活 - 跨越流程的软件控制，使流程可以按照业务的需要重新设计。
• 业务流程改进 - 对流程的关注，使它们趋向于流畅和简单

    我认为他们还遗漏了一个使用工作流系统最重要的因数：提高对迭代开发的支持。如果软件中业务流程部分不容易更改，组织就会花很大的精力在开发前的业务流程分析中，希望一次成功。但可悲的是，在任何软件项目开发中，这都很少能实现。工作流系统使得新业务流程很容易部署，业务流程相关的软件可以一种迭代的方式开发，因此使用工作流系统使开发更有效、风险更低。

缺失的一环（Missing link）

    我确实认为工作流系统是企业应用开发中缺失的一环。将企业业务流程逻辑在企业级软件中实现的缺省方式是分散的。这意味着业务流程逻辑散布在各种系统中，如EJB、数据库触发器、消息代理等等。这样得到的软件难于维护，结果，企业只能将改变业务流程软件作为最后的选择。他们经常能够做的是，改变流程以适应软件。上述问题也适用于采用大型外部ERP软件包的企业。进一步，假设我们认识到这个问题，并打算将一个流程相关的代码都集中起来。对于一个流程来说这很不错，但当你要实现多个流程时，你会看到管理状态和流程变量的代码被到处复制。最后，我们会整理这些代码放到一个集中的库中。好，...这就是一个工作流管理系统了，不用费心自己来实现，你可以从本文后面的列表中选择一个。

A closer look

WFMS interfaces

    一个工作流管理系统以流程定义作为输入。在这里，可以将流程定义看作UML活动图、UML状态图或者有限状态机。在提交一张费用单据、申请休假、要求一个报价、...之后，工作流系统负责维护这些流程定义的执行状态和上下文。为此，需要通知工作流系统状态的变化。运行流程的状态变化可以记录下来，以备监控管理。

Figure 2: Interfaces of a WFMS

• 定义   工作流系统的定义接口使流程开发人员能够部署流程定义。注意，这里的“流程开发人员”可以是业务分析师和软件开发人员的组合。

  圈套（Pitfall） 许多工作流管理系统的开发商想使你相信，通过使用他们的图形化流程开发工具，只要业务分析师就可以生成流程定义。这种幻想源于“编程很难”这样的事实。开发商的销售人员喜欢说“看，你不用写一行代码”。不用写代码是好事，可大部分开发商在这点上走的太远，忽略了在某些场合提供一种将代码集成到流程定义中的机制是很适合的。在将工作流系统作为EAI平台时，必须在流程中集成代码。开发流程定义需要业务分析师和软件开发人员的合作。一个好的图形流程设计工具应该能够支持这种合作。

• 执行   执行接口使用户和系统可以操作流程实例。流程实例是流程定义的执行。流程定义的控制流通过状态机描述。执行接口的两个主要方法是启动一个流程实例和通知工作流系统一个状态结束了。
• 应用   应用接口代表了由工作流系统发起的工作流系统和外部系统之间的交互。当一个用户或系统操作一个流程实例的运行时，会生成一些事件（如一个迁移的执行）。流程定义中可以指定一段响应一个事件的可执行代码逻辑，这段代码和组织内外部的其他系统打交道。
• 监控   管理人员通过监控接口获得流程运行的确切数据。有时，运行日志也可用于审计。

流程定义的四个层次

    在下面这部分，我尝试回答这样的问题“什么是流程定义包括的内容？”。这是从各种规范和工具所使用模型的原则和概念中总结得来的，反映了大部分模型中通用的基本思想。流程定义的内容可以分为四个不同的层次：状态（state）、上下文（context）、程序逻辑（programming logic）和用户界面（UI）。

状态层

    所有状态和控制流的表述，都属于业务流程的状态层。标准编程语言中的控制流来源于Von Neuman体系。控制流定义了必须被执行的指令的顺序，控制流由我们书写的命令、if语句、循环语句等确定。在业务流程中的控制流基本与此一致。但在业务流程中不是使用命令而是使用状态作为基本元素。

    在流程中，状态 (或者说等待状态)代表了一种对外部参与者（actor）的依赖。状态的意思就像“现在X系统或某某人必须作某些事，在此等待直到参与者通知这些任务已完成”。状态定义了一种对外部提供结果的依赖。状态典型的例子是批准步骤（step）。

    流程定义中的状态也指定了执行依赖于哪个参与者。在活动图中，泳道（swimlanes）的标注代表这些参与者的名字。工作流系统使用这些信息构建任务列表，这是一般工作流系统都有的功能。如前所述，参与者可以是人也可以是系统。对于需要人参与的状态，工作流系统必须在运行时计算出具体的个人。这样的计算使工作流系统必须依赖于组织结构信息。关于这方面的一篇非常有趣的文章是在further reading section提到的“工作流应用中的组织管理”（ 'Organizational Management in Workflow Applications'）。

    流程定义的控制流包含一组状态和它们之间的关系。状态之间的逻辑关系描述了哪些执行路径可以同时执行，那些不可以。同步执行路径用分叉（forks）和联合（joins）建模，异步执行路径用判断（decisions）和合并（ merges）建模。注意在大多数模型中，在每个状态之前都有一个隐式合并。

    UML活动图经常被用来做业务流程建模。作为一种直观和通用的表达，活动图在图形表述上有一个主要问题，就是没有区分状态和动作，它们都用活动来表示。缺少这种区分（导致状态概念的缺失）是学术派对UML活动图的主要批评。UML活动图的第二个问题是在UML2.0版中引入的。当多个迁移（transitions）到达一个活动时，以前的版本规定这是一个缺省合并（merge），在2.0版中规定这是一个需要同步的缺省联合（join）。在我看来，UML活动图的图形部分仍旧可以用来对业务流程状态层次建模，只要使用时对两条构建语义作如下的变化：

1. 在用图形表述业务流程时，只建模状态层（状态和控制流），不要包括动作。这意味着图形中的矩形都是状态而不是活动
2. 如果多个迁移到达一个状态，缺省定义为不需要同步的合并（merges）

    在流程运行过程中，工作流系统用一个令牌（token）作为指针跟踪流程的状态。这相当于Von Neuman体系中的程序计数器。当令牌到达一个状态时，它被分配给工作流系统等待的外部参与者。外部参与者可以是个人、组织或者计算机系统。我们定义流程运行的执行人或系统为“参与者”（actor）。只有在工作流系统将令牌分配给一个参与者时，才需要访问组织结构信息。工作流系统通过分配令牌构建任务列表。

上下文层

    流程上下文变量（process context variable） ，或简称变量，是与流程实例相关的变量。流程开发人员可以使用流程变量存储跨越流程实例整个生命周期的数据。一些工作流管理系统有固定数目的数据类型，另一些你可以定义自己的数据类型。

    注意变量也可以用来存放引用（ references）。一个变量可以引用如数据库中的记录、网络上的文件。什么时候使用引用，取决于使用引用数据的其他应用。

    和流程变量相关的另一个令人感兴趣的方面是：工作流系统如何将数据转化为信息。工作流是用于组织内部跨越各种异构系统实现任务和数据协同的。对于业务流程中人工执行的任务，工作流系统负责从其他相关系统，如SAP、数据库、CRM系统、文档管理系统收集数据。在业务流程的每一个人工步骤，只有相关联的数据项被从异构系统中收集和计算。通过这种方式，从不同系统来的数据被转换并展现为信息。

程序逻辑层

    如前所述，动作是在流程运行过程中，工作流系统响应指定的事件（event）执行的一段程序逻辑（programming logic）。程序逻辑可以是二进制或源代码形式的、用任何语言或脚本编写的软件。程序逻辑层是所有这些软件片断和关于在什么事件发生时调用它们的信息的组合。程序逻辑的例子包括发Email、通过消息代理发消息、从ERP系统中拿数据和更新数据库。

用户界面层

工作流全景

可执行流程与工作流管理系统的比较（Executional processes versus a WFMS）

    当前在BPM领域中，关于可执行业务流程的规范有趋向于统一集中的趋势。 XLANG, WSFL 和BPML合并为基于交互（消息交换）的BPEL。BPEL在面向服务体系结构(SOA)的大背景下定义。它的前提条件之一是涉及的服务必须用WSDL声明。BPEL规定了一套XML语法，这套语法可以看作一种编程语言，用来描述包括对WSDL定义的服务调用的控制流。

    在可执行业务流程和基于状态的工作流管理系统所使用的方法中，我注意到了三点主要的区别：

• 基于状态与面向消息：基于状态的工作流系统以状态（或者活动）概念为中心。工作流引擎维护状态并计算从一个状态到另一个状态的迁移。另一方面，像BPEL这样的可执行流程以对输入消息响应的定义为中心。一组这些响应外加其他信息（other bells and whistles）可以看作一个业务流程。这也解释了为什么BPEL可以看作是对基于状态的工作流系统的某些方面的补充。一个响应输入消息的BPEL onMessage事件处理器，可以在工作流状态之间的迁移中执行。
• 流程实例ID与消息相关处理：可执行业务流程的复杂性之一来自消息相关性的处理。流程描述的一部分必须说明BPEL引擎如何从输入消息中确定具体流程的标识。这必须基于输入消息的一个数据项。而工作流系统在每个流程实例生成同时生成了实例ID，客户端在后续调用引擎API时使用这个ID。
• 工作流引擎API与抽象服务端点（endpoint）：工作流系统提供一组集中的API，客户端通过调用API完成与所有流程实例的交互。在可执行业务流程中，每个流程表现为一个服务。这意味着对于每个流程定义都有一个不同的访问点。

学术界

开放源代码项目

    最后我们看看真实世界中的工作流管理系统。选择一个工作流管理系统是一件困难的事情，但有选择总比没有选择好。:-) 本文阐述工作流基本概念的目的之一，就是使你能够作更好的选择。但我也意识到，对于现在的软件架构师来说，选择工作流系统是一件最具挑战性的工作。

    下面的列表来源于三个地方：my previous article, the list of Carlos E Perez, 和 list by Topicus.

• jBpm - jBpm是本文作者编写的一个灵活可扩展的工作流管理系统。作为jBpm运行时server输入的业务流程使用简单强大的语言表达并打包在流程档案中。jBmp将工作流应用开发的便利性和杰出的企业应用集成（EAI）能力结合了起来。jBmp包括一个Web应用程序和一个日程安排程序。jBmp是一组J2SE组件，可以作为J2EE应用集群部署。
• OpenEbXML - OpenebXML项目致力于提供一个ebXML框架，主要支持不久将由 UN/CEFACT和OASIS发布的ebXML规范2.0版。
• Werkflow - Werkflow是一个灵活可扩展的基于流程和状态的工作流引擎。它的目标是满足可以想象的所有工作流程，从企业级的业务流程到小范围的用户交互流程。通过使用可插拔和分层结构，可以方便地容纳各种工作流语义。
• OSWorkflow - OSWorkflow最独到之处是绝对的灵活。
• wfmOpen - WfMOpen是WfMC和OMG中所谓工作流设施（workflow facility） (工作流引擎)的J2EE实现。工作流通过扩展的XPDL描述。
• OFBiz - OFBiz工作流引擎基于WfMC和OMG的规范，使用XPDL作为流程定义语言。
• ObjectWeb Bonita - Bonita是一个符合WfMC规范、灵活的协同工作流系统。 对于各种动作如流程概念建模、定义、实例化、流程控制和用户交互等提供了全面的集成图形工具。 100% 基于浏览器、使用SOAP和XML数据绑定技术的Web Services封装了已有的工作流业务方法并将它们以基于J2EE的Web Service形式发布。基于活动预测模型的第三代工作流引擎。
• Bigbross Bossa -速度非常快、轻量级的引擎，使用富有表达能力的Petri网定义工作流，不要求关系数据库，使用简单，能和Java应用集成。事实上，它是按嵌入式设计的。
• XFlow - XFlow运行于EJB和servlet容器中。
• Taverna - Taverna项目的目标是提供一种语言和软件工具，方便在eScience中使用工作流和分布计算技术。
• Enhydra Shark - Shark完全基于WfMC和OMG标准，使用 XPDL作为工作流定义语言。流程和活动的存储使用Enhydra DODS。
• PowerFolder - PowerFolder包括开发人员使用的studio，管理环境和一个运行时引擎。
• Breeze - Breeze一个轻量级、跨平台、基于组件的工作流引擎原型。
• Open Business Engine - Open Business Engine是一个开放源码的Java工作流引擎，支持WfMC规范，包括接口1（XPDL）、接口2/3（WAPI）和接口5。OBE为活动的运行提供了一个可控的集中环境。OBE主要基于J2EE实现。
• OpenWFE - OpenWFE是一个开放源码的Java工作流引擎。 它包括可升级的三个组件：引擎、工作列表和Web界面。它的流程定义语言虽然使用XML格式，其灵感来源于 Scheme，一种Lisp方言。
• Freefluo - Freefluo是一个使用Web Service的工作流协同工具，可以处理WSDL的Web Service调用。支持两种XML格式的工作流语言：IBM的WSFL和XScufl。Freefluo非常灵活，它的核心是不与任何工作流语言或执行架构关联的可重用协同框架。 Freefluo包括可执行使用WSFL一个子集描述的工作流的运行库。
• ZBuilder - ZBuilder3是第二代工作流开发管理系统，也是一个开放源码产品。它为不同的工作流引擎和工作流定义了一组标准的JMX管理接口。
• Twister - Twister的目标是提供新一代、易集成、应用Java领域中最新成果、面向B2B的工作流解决方案。流程引擎基于BPEL业务流程规范和Web Service标准。
• Con:cern - con:cern工作流引擎基于扩展的案例（case）处理方法，流程由一组具有前后条件的活动组成。

商业软件提供商

• Bea's WLI
• Carnot
• Dralasoft
• Filenet
• Fujitsu's i-Flow
• IBM's holosofx tool
• Intalio
• Joinwork （译者加:-) ）
• Lombardi
• Oakgrove's reactor
• Oracle's integration platform
• Q-Link
• SAP's NetWeaver
• Savvion
• Seebeyond
• Sonic's orchestration server
• Staffware
• Ultimus
• Versata
• WebMethod's process modeling

工具目录

• http://dmoz.org/Computers/Software/Workflow/Products/
• A collection of links to tools for modelling business processes and workflows maintained by Bart-Jan Hommes at TU Delft, the Netherlands.

规范

    Michael zur Muehlen作了一个所有工作流相关规范的介绍性的幻灯片，很不错。

    我同意John Pyke 和 Wil van der Aalst 的观点：工作流标准还处于制定阶段。现在存在大量相互丛叠的规范。

    在我看来，导致规范如此之多而同时每个规范的应用又很有限的原因是，在工作流最基础概念上大家达成的共识很少。工作流是最容易让你感到心烦的话题，因为工作流本身的概念会和其他相关概念和技术混淆在一起。可以举一个具体的例子，比如说工作流完全是对Web Service的补充。你可以通过暴露接口以Web Service的方式访问一个工作流管理系统，但是不能假定总是必须通过Web Service接口访问工作流系统接口。一些规范造成了这样的假设。除了Web Service，其他容易混淆的概念和技术包括：Email、流程之间的通讯、Web应用和组织结构。

    在工作流领域第一个致力于标准化工作的是Workflow Management Coalition (WfMC)，开始于 1993。 WfMC发布的参考模型很不错，它定义了工作流管理系统和其他相关部分之间的接口。WfMC的另一项成果是XPDL规范。 XPDL定义了描述工作流声明部分（declarative part）的XML结构。我个人认为，参考模型和XPDL是目前最好的规范。

• JSR 207: Java的流程定义 -是由Java Community Process (JCP) 发起，如何在J2EE应用服务器中实现业务流程自动化的标准。其基本模型是定义一个特殊类型的ejb session bean，作为一个业务流程的接口。JSR207标准化一组XML元标记（meta tags）作为JSR175元数据的一部分。JSR207 将session bean和元数据作为ejb容器的输入，然后生成绑定方法的代码，这些方法在元数据中描述。此规范还处于初级阶段，没有发布任何内容。专家小组成立于 March 2003.
• WfMC's XPDL - WfMC是由约300家成员参加的组织，基于参考模型定义了一系列的标准。参考模型用用例（use case）的形式描述了工作流系统和其他相关部分之间的关系。XPDL是WfMC制定的描述业务流程控制流（control flow ）的XML格式规范。
• ebXML's BPSS - ebXML是协同流程的相关标准集，主要关注不同公司流程之间的通讯。可以看作EDI的继承者。 ebXML是由OASIS和UN/CEFACT联合发起。 BPSS 是ebXML的规范，其中的概念和本文阐述的很接近。
• BPMI's BPML & WSCI - (Intalio, Sun, SAP, ...)BPMI 也定义了一个规范 (BPMN) ，描述如何将“可执行”业务流程可视化的表现。
• BPEL - (Microsoft, BEA, IBM, SAP & Siebel) BPEL由一系列基于消息交换的规范（ XLANG, WSFL, BPML）产生。还有一个将此规范引入到Java的提案: BPELJ。 此规范描述如何处理输入的消息，而不是对流程状态进行建模。就像本文提到的，它不是一个关于业务流程规格化定义的规范。简单的说，可以将它看作XML形式的编程语言，提供将WSDL-Services组合成控制流的能力。顾名思义，此规范重点在（也不只限于）Web Service。
• OMG's Workflow management facility - 基于WfMC规范，定义如何向CORBA转换。
• UML - UML定义了建模和设计软件系统的9类图。每类图包括可视化的表示和语义。其中活动图的目的就是要可视化的表现业务流程。 注意到在一个流程定义包含四个层次的内容，我想指出的是：一个流程定义包含的内容远远多于它的可视化部分。UML只涉及了可视化部分。
• RosettaNet - RosettaNet主要定义了一组 Partner Interface Processes (PIP). 一个 PIP 描述了一个有两个交易参与者、包括消息格式的流程。
• UBL - The Universal Business Language (UBL)定义了用于不同组织间通讯的XML文档标准库。可以看作是对ebXML的补充，因为ebXML只定义了建立组织间流程的基础。此规范的竞争对手是 RosettaNet标准中的一个子集。

结论

    我在本文中指出工作流市场还属于年轻而又混乱（young and wild）的阶段，但已经有可靠的工具存在了:

1. 到目前，像J2EE和.NET这样成熟的集成平台才可用。在这样一个平台上运行工作流管理系统才能真正发挥工作流系统的附加价值。这也是为什么只有在今天，工作流系统才被重新发现。
2. 在 'The case for workflow'一节，我们介绍了引入工作流管理系统，是如何同时在技术和业务上带来投资回报的。
3. 工作流在技术发展曲线的位置表明，BPM和工作流中使用的概念还需要明确。
4. “开放源代码项目”和“商业软件提供商”列表中的工具，可以让你获得工作流和业务流程管理的益处。

    从以上所有这些中能得到的结论是：

1. 规范还没有成熟，没有标准被大范围采用
2. 对于现在想应用BPM的公司来讲，比较工作流系统是一个极其困难的挑战
3. 尽管标准化工作慢了一拍，可好的工作流管理系统还是有的。这对于已经在挑选工作流系统的组织来说是一个好消息。

    我希望本文能够激发你对工作流的兴趣并且能够为你进行有效的对比提供正确的背景知识。

Further reading

• Workflow Patterns -Wil van der Aalst教授的工作流模式学术研究网站
• ebpml.org - 有关业务流程管理和工作流的网站，信息量大、全面
• Business process management group - The Business Process Management Group (founded in 1992) is a global business club exchanging ideas and best practice in business process and change management.
• Enix - 英国流程管理顾问公司，在网站上有不错的内容
• ebizq.net - Commercial community that has booths, webinars and other interesting stuff put together in a nice website.
• An introduction to petri nets - The title says it all.
• Organizational Management in Workflow Applications- An interesting article that discusses the relation between business processes and the organisational data involved.
• Web services orchestration - an HP-paper that reviews the emerging technologies tools and standards. (Januari 2003)
• Business process standards for web services - An article that discusses the various aspects involved in workflow and BPM.

设想这样一种情形：你突然口渴，需要一杯水来缓解，从心情上来讲，当然是越快越好了。通常，一杯水的产生包括从水源（井水、河水或江水、甚至海水等）抽取，通过管道传输和设备净化，才到达你饮水的容器中。上述过程是必须的，但并不是每一杯水的产生都必须把上述过程重复一次。你可以用一个大一点的容器（例如缸或罐等）来盛大量的水，喝水之前分到杯子小部分中即可，你的代价只是把水从缸转移到杯子；你还可以在大量用水（例如洗澡或洗衣服等）时，只需打开水阀，而不必临时铺设通往水源的管道和购买净化水的设备。因为水是人们生活不可缺少的东西，每时每刻都在被大量地使用，而且物理本质也完全相同，所以政府会铺设管道和建设水处理站，完成那些比较困难的工作，达到资源共享的目的，而你也可针对自己的需求，用容器来盛那些具有特定用途的水。本文将要和你讨论的高速缓存和连接池与上述特定容器和传输管道有很多相似之处，它们都达到了同一个目的：在满足用户意愿的前提下，尽可能地共享资源，以提高整个系统的性能。

高速缓存和连接池是数据访问中的重要技术，某些情况下的应用对访问数据库的性能有巨大的提高，而且都得到了数据库业界的普遍支持。前者由DBMS厂商针对自己的数据库实现，提供可供用户配置的方案；后者是JDBC的一个标准接口，由支持J2EE技术的应用服务器厂商提供具体的实现，而你的Java程序代码无需更改。本文将向你简单介绍高速缓存和连接池的概念和机制，并以PointBase数据库为例向你展示高速缓存的应用，而一个简单的连接池应用场景将向你描述应用的条件和提高的性能。

Cache（高速缓存）和Connection Pool（连接池）的概念和机制

它们不是数据库独有的技术，但却得到数据库业界的普遍支持，并在其它数据存取和对象复用领域有很多类似的应用。

Cache（高速缓存）
作为个人计算机的日常使用者，你肯定听说过这些名词：Cache（高速缓存）、Memory（内存）、Hard disk（硬盘）。它们都是数据存取单元，但存取速度却有很大差异，呈依次递减的顺序。对于CPU来说，它可以从距离自己最近的Cache高速地存取数据，而不是从内存和硬盘以低几个数量级的速度来存取数据。而Cache中所存储的数据，往往是CPU要反复存取的数据，有特定的机制（或程序）来保证Cache内数据的命中率（Hit Rate）。因此，CPU存取数据的速度在应用高速缓存后得到了巨大的提高。

对于数据库来说，厂商的做法往往是在内存中开辟相应的区域来存储可能被多次存取的数据和可能被多次执行的语句，以使这些数据在下次被访问时不必再次提交对DBMS的请求和那些语句在下次执行时不必再次编译。

因为将数据写入高速缓存的任务由Cache Manager负责，所以对用户来说高速缓存的内容肯定是只读的。需要你做的工作很少，程序中的SQL语句和直接访问DBMS时没有分别，返回的结果也看不出有什么差别。而数据库厂商往往会在DB Server的配置文件中提供与Cache相关的参数，通过修改它们，可针对我们的应用优化Cache的管理。下图是在Win2K中配置MS Access数据源的界面，在"驱动程序"部分你可设置的页超时和缓冲区大小就是和Cache有关的参数。在后面的讨论中，我将展示一个更复杂的数据库，向你解释Cache对访问数据库性能的影响和如何寻找最优的配置方案。

Connection Pool（连接池）

池是一个很普遍的概念，和缓冲存储有机制相近的地方，都是缩减了访问的环节，但它更注重于资源的共享。下图展示了建立"调制解调器池"以共享调制解调器资源的VPN拨号方案：

对于访问数据库来说，建立连接的代价比较昂贵，因此，我们有必要建立"连接池"以提高访问的性能。我们可以把连接当作对象或者设备，池中又有许多已经建立的连接，访问本来需要与数据库的连接的地方，都改为和池相连，池临时分配连接供访问使用，结果返回后，访问将连接交还。

JDBC 1.0标准及其扩展中没有定义连接池，而在JDBC 2.0标准的扩展中定义了与连接池相关的接口。与接口对应的类由应用服务器厂商实现，你可在对服务器的管理过程中调节某个数据库连接池的参数。下图简略地描述了连接池的运行机制：

高速缓存的参数设定

在PointBase数据库DB Server的配置参数列表中，我们可以找到这几个参数：cache.checkpointinterval、cache.size、SQLCaching.size等。下表是对各个参数的描述：

参数名 参数描述
cache.checkpointinterval 检查点的时间间隔
cache.size 高速缓存的最大页数（素数时，性能最好）
SQLCaching.size 高速缓存中SQL语句的个数

对于cache.checkpointinterval来说，和前面Access界面中的页超时是一个概念，它指定了页面内容更新的时间间隔，这取决于你的应用对时效性的要求程度。

对于cache.size来说，指定了页面的个数，一般应设定为符合你查询结果的需求。至于为何是素数，我也纳闷，不过还是遵照厂商的指示吧。

对于SQLCaching.size来说，指定了存储的经过编译的SQL语句的个数，你可以把它设定为0，从而取消这个选项。

使用Cache后，性能到底有多大提高？我打开PointBase的Console通过JDBC驱动访问Server，将SQL菜单下的Timing Mode选上，以显示各个步骤的耗费时间。执行语句是：

SELECT * FROM PRODUCT_TBL

第一次访问，总计耗时1082毫秒，而编译耗时771毫秒。

紧接着的第二次访问，总计耗时仅为160毫秒，而编译耗时为0。

再接着的第三次访问，总计耗时仅为91毫秒，编译耗时也为0。

关闭Console，等待超过30秒之后，重新开启Console，执行相同的语句，总计耗时210毫秒，编译耗时为20毫秒。

自等待超过30秒之后，执行语句，总计耗时101毫秒，编译耗时为0。

由此可以看出，高速缓存的应用大大提高了访问数据库的性能，而其参数的设定则要依据前面对它们的描述来进行，需要你仔细阅读数据库的配置文档。

连接池的设置和应用

我选择IBM公司的应用服务器平台WebSphere来给大家演示连接池的设置，使你面对友好的Web界面，可以体验到非常简易的操作场景。

首先，我们进入WebSphere的管理控制台，这是一个非常漂亮的Web界面：

紧接着，我选定一个数据源：Session Persistence datasource，就可看到这个数据源的属性配置了。在这儿，仅仅列举和连接池有关的属性：

Minimum Pool Size 池中保持的连接的最小数目；有新的请求，且没有激活连接可供使用时，池中连接数将增大，到最大连接数为止
Maximum Pool Size 池中保持的连接的最大数目；当这个数目达到，且没有激活连接可供使用时，新的请求将等待
Connection Timeout 当连接数达到最大值，且激活连接都在被使用时，新的请求等待的时间
Idle Timeout 连接可在池中闲置的时间；超过将释放资源，到最小连接数为止
Orphan Timeout 连接在被应用控制时，可闲置的时间；超过将返回池中

你可以根据需要来修改这些数值，以满足你的应用需要。接下来，我们讨论一下连接池的应用。

EJB访问数据库（场景1，使用JDBC 1.0） import java.sql.*;
import javax.sql.*;
...
public class AccountBean implements EntityBean {
...
public Collection ejbFindByLastName(String lName) {
try {
String dbdriver = new initialContext().lookup("java:comp/env/DBDRIVER").toString();
Class.forName(dbdriver).newInstance();
Connection conn = null;
conn = DriverManager.getConnection("java:comp/env/DBURL", "userID", "password");
...
conn.close();
}
...
}

如果EntityBean是一个共享组件，那么每次客户请求时，都要建立和释放与数据库的连接，这成为影响性能的主要问题。

EJB访问数据库（场景2，使用JDBC 2.0） import java.sql.*;
import javax.sql.*;
// import here vendor specific JDBC drivers

public ProductPK ejbCreate() {
try {
// initialize JNDI lookup parameters
Context ctx = new InitialContext(parms);
...
ConnectionPoolDataSource cpds = (ConnectionPoolDataSource)ctx.lookup(cpsource);
...
// Following parms could all come from a JNDI look-up
cpds.setDatabaseName("PTDB");
cpds.setUserIF("XYZ");
...
PooledConnection pc = cpds.getPooledConnection();
Connection conn = pc.getConnection();
...
// do business logic
conn.close();
}
...
}
EJB组件利用JNDI的lookup()方法定位数据库的连接池资源，利用getConnection()方法得到已经打开的数据库连接，而用close()来释放连接，放回池中。因此，与场景1相比，少了与数据库建立物理连接的损耗。对于原本要频繁打开和关闭物理连接的应用来说，通过这种建立逻辑连接并复用的方法，性能肯定能够得到大幅度提高。

性能问题的深远思索

性能问题并不局限于数据库的应用上，而是存在于每个软件系统中。我们希望软件系统付出的最小，而获得的最大，因而无时无刻不在优化它们。通过《Java程序访问数据库的速度瓶颈问题的分析和解决》和本文，我对Java程序访问数据库的性能问题做了分析，并提供了优化Java程序的解决方案，希望对你有所帮助。

也许你会关心碰到类似的性能问题时应如何分析和解决，我就针对此次探讨"访问数据库的速度瓶颈"问题的过程中碰到的难题、网友的意见和自己的体会，作一个关于"方法论"的经验总结，希望能够抛砖引玉，更好地解决类似的问题。

解决性能问题的几条经验

不要让硬件的低配置成为软件正常运行的障碍，后者有升级前者的需求，请立即满足；经常碰到这样的问题"P166+64M的机子跑Win2K+MySql+JBoss，能跑么？"我在回答"可以"的同时只有对着屏幕发呆了。
尽量使用商业软件，并享受良好的售后技术支持；如果你没有黑客精神，请不要使用自由软件。
分析好自己的问题，也许它的本质和他人的不同；没有一把钥匙可打开的任一把锁。
确定瓶颈环节的位置；解决了瓶颈问题，往往整个的性能问题就解决了，千万不要抓着边缘的问题不放。
将瓶颈环节细分为多个顺序的流程，用逐个替代的方法来试探瓶颈的核心位置；细分问题使你都问题有更进一步的了解。
做自己能做的和该做的事情，始终面向自己的现实问题；不要尝试那些应该由厂商解决的问题（例如，自己写个JDBC驱动）。
他人的方案只供自己参考，解决要靠自己思考；你我应用的情形不同，应用解决方案要在理解他人的方案之后。
观察新技术，应用新技术；它往往包含了前人对问题解决的思路，只是对你来说不可见。
问题得到解决后，立即罢手，并汇报结果；在现实问题得到解决后，没有必要花费精力在非核心的问题上，也许它们永远不会被碰到，不要假想问题让自己解决。
上述经验为个人即兴的总结，并未有严谨的逻辑推导，仅代表我解决技术问题的思路，供你碰到类似问题时参考。

可以提前告诉大家的是，下一篇文章我将把主题转移到JDO的介绍和讨论上。这个陌生的API已经进入Final Draft了，可它到底能够给数据存取带来什么好处，和JDBC有什么关联的地方，《JDO（Java Data Object）的发展和介绍》将向你娓娓道来。

设想这样一种情形：你突然口渴，需要一杯水来缓解，从心情上来讲，当然是越快越好了。通常，一杯水的产生包括从水源（井水、河水或江水、甚至海水等）抽取，通过管道传输和设备净化，才到达你饮水的容器中。上述过程是必须的，但并不是每一杯水的产生都必须把上述过程重复一次。你可以用一个大一点的容器（例如缸或罐等）来盛大量的水，喝水之前分到杯子小部分中即可，你的代价只是把水从缸转移到杯子；你还可以在大量用水（例如洗澡或洗衣服等）时，只需打开水阀，而不必临时铺设通往水源的管道和购买净化水的设备。因为水是人们生活不可缺少的东西，每时每刻都在被大量地使用，而且物理本质也完全相同，所以政府会铺设管道和建设水处理站，完成那些比较困难的工作，达到资源共享的目的，而你也可针对自己的需求，用容器来盛那些具有特定用途的水。本文将要和你讨论的高速缓存和连接池与上述特定容器和传输管道有很多相似之处，它们都达到了同一个目的：在满足用户意愿的前提下，尽可能地共享资源，以提高整个系统的性能。

高速缓存和连接池是数据访问中的重要技术，某些情况下的应用对访问数据库的性能有巨大的提高，而且都得到了数据库业界的普遍支持。前者由DBMS厂商针对自己的数据库实现，提供可供用户配置的方案；后者是JDBC的一个标准接口，由支持J2EE技术的应用服务器厂商提供具体的实现，而你的Java程序代码无需更改。本文将向你简单介绍高速缓存和连接池的概念和机制，并以PointBase数据库为例向你展示高速缓存的应用，而一个简单的连接池应用场景将向你描述应用的条件和提高的性能。

Cache（高速缓存）和Connection Pool（连接池）的概念和机制

它们不是数据库独有的技术，但却得到数据库业界的普遍支持，并在其它数据存取和对象复用领域有很多类似的应用。

Cache（高速缓存）
作为个人计算机的日常使用者，你肯定听说过这些名词：Cache（高速缓存）、Memory（内存）、Hard disk（硬盘）。它们都是数据存取单元，但存取速度却有很大差异，呈依次递减的顺序。对于CPU来说，它可以从距离自己最近的Cache高速地存取数据，而不是从内存和硬盘以低几个数量级的速度来存取数据。而Cache中所存储的数据，往往是CPU要反复存取的数据，有特定的机制（或程序）来保证Cache内数据的命中率（Hit Rate）。因此，CPU存取数据的速度在应用高速缓存后得到了巨大的提高。

对于数据库来说，厂商的做法往往是在内存中开辟相应的区域来存储可能被多次存取的数据和可能被多次执行的语句，以使这些数据在下次被访问时不必再次提交对DBMS的请求和那些语句在下次执行时不必再次编译。

因为将数据写入高速缓存的任务由Cache Manager负责，所以对用户来说高速缓存的内容肯定是只读的。需要你做的工作很少，程序中的SQL语句和直接访问DBMS时没有分别，返回的结果也看不出有什么差别。而数据库厂商往往会在DB Server的配置文件中提供与Cache相关的参数，通过修改它们，可针对我们的应用优化Cache的管理。下图是在Win2K中配置MS Access数据源的界面，在"驱动程序"部分你可设置的页超时和缓冲区大小就是和Cache有关的参数。在后面的讨论中，我将展示一个更复杂的数据库，向你解释Cache对访问数据库性能的影响和如何寻找最优的配置方案。

Connection Pool（连接池）

池是一个很普遍的概念，和缓冲存储有机制相近的地方，都是缩减了访问的环节，但它更注重于资源的共享。下图展示了建立"调制解调器池"以共享调制解调器资源的VPN拨号方案：

对于访问数据库来说，建立连接的代价比较昂贵，因此，我们有必要建立"连接池"以提高访问的性能。我们可以把连接当作对象或者设备，池中又有许多已经建立的连接，访问本来需要与数据库的连接的地方，都改为和池相连，池临时分配连接供访问使用，结果返回后，访问将连接交还。

JDBC 1.0标准及其扩展中没有定义连接池，而在JDBC 2.0标准的扩展中定义了与连接池相关的接口。与接口对应的类由应用服务器厂商实现，你可在对服务器的管理过程中调节某个数据库连接池的参数。下图简略地描述了连接池的运行机制：

高速缓存的参数设定

在PointBase数据库DB Server的配置参数列表中，我们可以找到这几个参数：cache.checkpointinterval、cache.size、SQLCaching.size等。下表是对各个参数的描述：

参数名 参数描述
cache.checkpointinterval 检查点的时间间隔
cache.size 高速缓存的最大页数（素数时，性能最好）
SQLCaching.size 高速缓存中SQL语句的个数

对于cache.checkpointinterval来说，和前面Access界面中的页超时是一个概念，它指定了页面内容更新的时间间隔，这取决于你的应用对时效性的要求程度。

对于cache.size来说，指定了页面的个数，一般应设定为符合你查询结果的需求。至于为何是素数，我也纳闷，不过还是遵照厂商的指示吧。

对于SQLCaching.size来说，指定了存储的经过编译的SQL语句的个数，你可以把它设定为0，从而取消这个选项。

使用Cache后，性能到底有多大提高？我打开PointBase的Console通过JDBC驱动访问Server，将SQL菜单下的Timing Mode选上，以显示各个步骤的耗费时间。执行语句是：

SELECT * FROM PRODUCT_TBL

第一次访问，总计耗时1082毫秒，而编译耗时771毫秒。

紧接着的第二次访问，总计耗时仅为160毫秒，而编译耗时为0。

再接着的第三次访问，总计耗时仅为91毫秒，编译耗时也为0。

关闭Console，等待超过30秒之后，重新开启Console，执行相同的语句，总计耗时210毫秒，编译耗时为20毫秒。

自等待超过30秒之后，执行语句，总计耗时101毫秒，编译耗时为0。

由此可以看出，高速缓存的应用大大提高了访问数据库的性能，而其参数的设定则要依据前面对它们的描述来进行，需要你仔细阅读数据库的配置文档。

连接池的设置和应用

我选择IBM公司的应用服务器平台WebSphere来给大家演示连接池的设置，使你面对友好的Web界面，可以体验到非常简易的操作场景。

首先，我们进入WebSphere的管理控制台，这是一个非常漂亮的Web界面：

紧接着，我选定一个数据源：Session Persistence datasource，就可看到这个数据源的属性配置了。在这儿，仅仅列举和连接池有关的属性：

Minimum Pool Size 池中保持的连接的最小数目；有新的请求，且没有激活连接可供使用时，池中连接数将增大，到最大连接数为止
Maximum Pool Size 池中保持的连接的最大数目；当这个数目达到，且没有激活连接可供使用时，新的请求将等待
Connection Timeout 当连接数达到最大值，且激活连接都在被使用时，新的请求等待的时间
Idle Timeout 连接可在池中闲置的时间；超过将释放资源，到最小连接数为止
Orphan Timeout 连接在被应用控制时，可闲置的时间；超过将返回池中

你可以根据需要来修改这些数值，以满足你的应用需要。接下来，我们讨论一下连接池的应用。

EJB访问数据库（场景1，使用JDBC 1.0） import java.sql.*;
import javax.sql.*;
...
public class AccountBean implements EntityBean {
...
public Collection ejbFindByLastName(String lName) {
try {
String dbdriver = new initialContext().lookup("java:comp/env/DBDRIVER").toString();
Class.forName(dbdriver).newInstance();
Connection conn = null;
conn = DriverManager.getConnection("java:comp/env/DBURL", "userID", "password");
...
conn.close();
}
...
}

如果EntityBean是一个共享组件，那么每次客户请求时，都要建立和释放与数据库的连接，这成为影响性能的主要问题。

EJB访问数据库（场景2，使用JDBC 2.0） import java.sql.*;
import javax.sql.*;
// import here vendor specific JDBC drivers

public ProductPK ejbCreate() {
try {
// initialize JNDI lookup parameters
Context ctx = new InitialContext(parms);
...
ConnectionPoolDataSource cpds = (ConnectionPoolDataSource)ctx.lookup(cpsource);
...
// Following parms could all come from a JNDI look-up
cpds.setDatabaseName("PTDB");
cpds.setUserIF("XYZ");
...
PooledConnection pc = cpds.getPooledConnection();
Connection conn = pc.getConnection();
...
// do business logic
conn.close();
}
...
}
EJB组件利用JNDI的lookup()方法定位数据库的连接池资源，利用getConnection()方法得到已经打开的数据库连接，而用close()来释放连接，放回池中。因此，与场景1相比，少了与数据库建立物理连接的损耗。对于原本要频繁打开和关闭物理连接的应用来说，通过这种建立逻辑连接并复用的方法，性能肯定能够得到大幅度提高。

性能问题的深远思索

性能问题并不局限于数据库的应用上，而是存在于每个软件系统中。我们希望软件系统付出的最小，而获得的最大，因而无时无刻不在优化它们。通过《Java程序访问数据库的速度瓶颈问题的分析和解决》和本文，我对Java程序访问数据库的性能问题做了分析，并提供了优化Java程序的解决方案，希望对你有所帮助。

也许你会关心碰到类似的性能问题时应如何分析和解决，我就针对此次探讨"访问数据库的速度瓶颈"问题的过程中碰到的难题、网友的意见和自己的体会，作一个关于"方法论"的经验总结，希望能够抛砖引玉，更好地解决类似的问题。

解决性能问题的几条经验

不要让硬件的低配置成为软件正常运行的障碍，后者有升级前者的需求，请立即满足；经常碰到这样的问题"P166+64M的机子跑Win2K+MySql+JBoss，能跑么？"我在回答"可以"的同时只有对着屏幕发呆了。
尽量使用商业软件，并享受良好的售后技术支持；如果你没有黑客精神，请不要使用自由软件。
分析好自己的问题，也许它的本质和他人的不同；没有一把钥匙可打开的任一把锁。
确定瓶颈环节的位置；解决了瓶颈问题，往往整个的性能问题就解决了，千万不要抓着边缘的问题不放。
将瓶颈环节细分为多个顺序的流程，用逐个替代的方法来试探瓶颈的核心位置；细分问题使你都问题有更进一步的了解。
做自己能做的和该做的事情，始终面向自己的现实问题；不要尝试那些应该由厂商解决的问题（例如，自己写个JDBC驱动）。
他人的方案只供自己参考，解决要靠自己思考；你我应用的情形不同，应用解决方案要在理解他人的方案之后。
观察新技术，应用新技术；它往往包含了前人对问题解决的思路，只是对你来说不可见。
问题得到解决后，立即罢手，并汇报结果；在现实问题得到解决后，没有必要花费精力在非核心的问题上，也许它们永远不会被碰到，不要假想问题让自己解决。
上述经验为个人即兴的总结，并未有严谨的逻辑推导，仅代表我解决技术问题的思路，供你碰到类似问题时参考。

可以提前告诉大家的是，下一篇文章我将把主题转移到JDO的介绍和讨论上。这个陌生的API已经进入Final Draft了，可它到底能够给数据存取带来什么好处，和JDBC有什么关联的地方，《JDO（Java Data Object）的发展和介绍》将向你娓娓道来。

以下内容选自B. S在自己主页上发表的FAQ

1. 请谈谈C++书。

没有，也不可能有一本书对於所有人来说都是最好的。不过对於那些真正的程序员来说，如果他喜欢从"经典风格"的书中间学习一些新的概念和技术，我推荐我的The C++ Programming Language, 1998年的第三版和特别版。那本书讲的是纯而又纯的C++，完全独立於平台和库（当然得讲到标准库）。该书面向那些有一定经验的程序员，帮助他们掌握C++，但不适合毫无经验的初学者入门，也不适合那些临时程序员品尝C++快餐。所以这本书的重点在於概念和技术，而且在完整性和精确性上下了不少功夫。如果你想知道为什麽C++会变成今天的模样，我的另一本书 The Design and Evolution of C++ 能给你满意的答案。理解设计的原则和限制能帮助你写出更好的程序。www.accu.org是最好的书评网站之一，很多有经验的程序员在此仗义执言，不妨去看看。

2. 学习C++要花多长时间？

这要看你说的"学习"是什麽意思了。如果你是一个Pascal程序员，你应该能很快地使你的C++水平达到与Pascal相近的程度；而如果你是一个C程序员，一天之内你就能学会使用C++进行更出色的C风格编程。另一方面，如果你想完全掌握C++的主要机制，例如数据抽象，面向对象编程，通用编程，面向对象设计等等，而此前又对这些东西不很熟悉的话，花上个一两年是不足为奇的。那麽是不是说这就是学习C++所需要的时间呢？也许再翻一番，我想打算成为更出色的设计师和程序员最起码也要这麽长的时间。如果学习一种新的语言不能使我们的工作和思想方式发生深刻
的变革，那又何苦来哉？跟成为一个钢琴家或者熟练掌握一门外语相比，学习一种新的 不同的语言和编程风格还算是简单的。

3. 了解C是学习C++的先决条件吗？

否 C++中与C相近的子集其实比C语言本身要好学，类型方面的错误会少一些，也不像C那样绕圈子，还有更好的支持库。所以应该从这个子集开始学习C++。

4. 要想成为真正的OO程序员，我是不是得先学习Smalltalk？

否。如果你想学Smalltaok，尽管去学。这种语言很有趣，而且学习新东西总是一个好主意。但是Smalltalk不是C++，而且把Smalltalk的编程风格用在C++里不会有什麽好结果。如果你想成为一个出色的C++程序员，而且也没有几个月的时间百无聊赖，请你集中力量学好C++以及其背後的思想。

5. 我如何开始学习C++？

这取决于你的基础和学习动机。如果你是个初学者，我想你最好找个有经验的程序员来帮助你，要不然你在学习和实践中不可避免的犯下的种种错误会大大地打击你的积极性。另外，即使你的编译器配备了充足的文档资料，一本C++书籍也永远是必不可少的，毕竟文档资料不是学习编程思想的好教材。

选择书籍时，务必注意该书是不是从一开始就讲授标准C++，并且矢志不渝地使用标准库机制。例如，从输入中读取一个字符串应该是这样的：

    string s;    // Standard C++ style
    cin >> s;

而不是这样的：

    char s[MAX];    /* Standard C style */
    scanf("%s",s);

去看看那些扎实的C++程序员们推荐的书吧。记住，没有哪本书对所有人来说都是最好的。另外，要写地道的C++程序，而避免用C++的语法写传统风格的程序，新瓶装旧酒没多大意义。（遗憾的是，目前在市面上的中文C++教材中，符合B. S的这个标准的可以说一本都没有，大家只好到网上找一些英文的资料来学习了。--译者）

6. 怎样改进我的C++程序？

不好说。这取决于你是怎麽使用该语言的。大多数人低估了抽象类和模板的价值，反过来却肆无忌惮地使用造型机制(cast)和宏。这方面可以看看我的文章和书。抽象类和和模板的作用当然是提供一种方便的手段建构单根的类层次或者重用函数，但更重要的是，它们作为接口提供了简洁的 逻辑性的服务表示机制。

7. 语言的选择是不是很重要？

是，但也别指望奇迹。很多人似乎相信某一种语言能够解决他们在系统开发中遇到的几乎所有问题，他们不断地去寻找完美的编程语言，然後一次次的失败，一次次的沮丧。另外一些人则将编程语言贬为无关紧要的细节，把大把大把的银子放在开发流程和设计方法上，他们永远都在用COBOL C和一些专有语言。一种优秀的语言，例如C++，能帮助设计者和程序员做很多事情，而其能力和缺陷又能够被清楚地了解和对待。

8. ANSI/ISO标准委员会是不是糟蹋了C++？

当然不是 他们（我们）的工作很出色。你可以在一些细节上找些歪理来挑刺，但我个人对於这种语言以及新的标准库可是欣欣然。ISO C++较之C++的以前版本更出色更有条理。相对於标准化过程刚刚开始之初，你今天可以写出更优雅 更易于维护的C++程序。新的标准库也是一份真正的大礼。由於标准库提供了strings, lists, vectors, maps以及作用于其上的基本算法，使用C++的方式已经发生了巨大的变化。

9. 你现在有没有想删除一些C++特性？

没有，真的。问这些问题的人大概是希望我回答下面特性中的一个：多继承 异常 模板和RTTI。但是没有它们，C++就是不完整的。在过去的N年中，我已经反复考虑过它们的设计，并且与标准委员会一起改进了其细节，但是没有一个能被去掉又不引起大地震。

从语言设计的角度讲，我最不喜欢的部份是与C兼容的那个子集，但又不能把它去掉，因为那样对於在现实世界里工作的程序员们来说伤害太大了。C++与C兼容，这是一项关键的设计决策，绝对不是一个叫卖的噱头。兼容性的实现和维护是十分困难的，但确实使程序员们至今受益良多。

但是现在，C++已经有了新的特性，程序员们可以从麻烦多多的C风格中解脱出来。例如，使用标准库里的容器类，象vector, list, map, string等等，可以避免与底层的指针操作技巧混战不休。

10. 如果不必和C兼容，你所创造的语言是不是就会是Java?

不是，差得远。如果人们非要拿C++和Java来作比较，我建议他们去阅读The Design and Evolution of C++，看看C++为什麽是今天这个样子，用我在设计C++时遵从的原则来检验这两种语言。这些原则与SUN的Java开发小组所持的理念显然是不同的。除了表面语法的相似性之外，C++与Java是截然不同的语言。在很多方面，Java更像Smalltalk（译者按：我学习Java时用的是Sun的培训教材，里面清楚地写道：Java在设计上采用了与C++相似的语法，与Smalltalk相似的语义。所以可以说Java与C++是貌合神离，与Smalltalk才是心有灵犀）。Java语言相对简单，这部分是一种错觉，部份是因为这种语言还不完整。随 时间的推移，Java在体积和复杂程度上都会大大增长。在体积上它会增长两到三倍，而且会出现一些实现相关的扩展或者库。这是一条每个成功的商业语言都必须走过的发展之路。随便分析一种你认为在很大范围内取得了成功的语言，我知道肯定是无有例外者，而且实际上这非常有道理。

上边这段话是在Java 1.1推出之前写的。我确信Java需要类似模板的机制，并且需要增强对於固有类型的支持。简单地说，就是为了基本的完整性也应该做这些工作。另外还需要做很多小的改动，大部份是扩展。1998年秋，我从James Gosling（Java语言的创始人--译者）那里得到一份建议书，说是要在Java中增加固有类型 操作符重载以及数学计算支持。还有一篇论文，是数学分析领域的世界级大师，伯克利大学的W. Kahan教授所写的How Java's Floating-Point Hurts Everyone Everywhere（"且看Java的浮点运算如何危害了普天下的芸芸众生"--译者），揭露了Java的一些秘密。

我发现在电视和出版物中关於Java的鼓吹是不准确的，而且气势汹汹，让人讨厌。大肆叫嚣凡是非Java的代码都是垃圾，这是对程序员的侮辱；建议把所有的保留代码都用Java重写，这是丧心病狂，既不现实也不负责任。Sun和他的追随者似乎觉得为了对付微软罪恶的"帝国时代"，就必须如此自吹自擂。但是侮辱和欺诈只会把那些喜欢使用不同编程语言的程序员逼到微软阵营里去。

Java并非平台无关，它本身就是平台。跟Windows一样，它也是一个专有的商业平台。也就是说，你可以为Windows/Intel编写代码，也可以为Java/JVM编写代码，在任何一种情况下，你都是在为一个属於某个公司的平台写代码，这些代码都是与该公司的商业利益扯在一起的。当然你可以使用任何一种语言，结合操作系统的机制来编写可供JVM执行的程序，但是JVM之类的东西是强烈地偏向于Java语言的。它一点也不像是通用的 公平的 语言中立的VM/OS。

私下里，我会坚持使用可移植的C++作大部份工作，用不同的语言作余下的工作。
（"Java is not platform-independent, it is the platform"，B. S的这句评语对於C++用户有 很大的影响，译者在国外的几个新闻组里看到，有些C++高手甚至把这句话作为自己的签名档，以表明对Java的态度和誓死捍卫C++的决心。实际上有很多程序员不光是把自己喜爱的语言当成一种工具，更当成一种信仰。--译者）

11. 您怎麽看待C#语言？

就C#语言本身我没什麽好说的。想让我相信这个世界还需要另外一个专有的语言可不是一件容易的事，而且这个语言还是专门针对某一个专有操作系统的，这就更让我难以接受。直截了当地说，我不是一个专有语言的痴迷者，而是一个开放的正式标准的拥护者。

12. 在做大项目时，您是不是真的推荐Ada，而不是C++？

当然不是。我不知道这是谁传出来的谣言，肯定是一个Ada信徒，要麽是过份狂热，要麽是不怀好意。

13. 你愿不愿意将C++与别的语言比较？

抱歉，我不愿意。你可以在The Design and Evolution of C++的介绍性文字里找到原因。

有不少书评家邀请我把C++与其它的语言相比，我已经决定不做此类事情。在此我想重申一个我很久以来一直强调的观点：语言之间的比较没什麽意义，更不公平。主流语言之间的合理比较要耗费很大的精力，多数人不会愿意付出这麽大的代价。另外还需要在广泛的应用领域有充份经验，保持一种不偏不倚 客观独立的立场，有 公正无私的信念。我没时间，而且作为C++的创造者，在公正无私这一点上我永远不会获得完全的信任。

人们试图把各种语言拿来比较长短，有些现像我已经一次又一次地注意到，坦率地说我感到担 。作者们尽力表现的公正无私，但是最终都是无可救药地偏向于某一种特定的应用程序，某一种特定的编程风格，或者某一种特定的程序员文化。更糟的是，当某一种语言明显地比另一种语言更出名时，一些不易察觉的偷梁换柱就开始了：比较有名的语言中的缺陷被有意淡化，而且被拐弯抹角地加以掩饰；而同样的缺陷在不那麽出名的语言里就被描述为致命硬伤。类似的，有关比较出名的语言的技术资料经常更新，而不太出名的语言的技术资料往往是几年以前的，试问这种比较有何公正性和意义可言？所以我对於C++之外的语言的评论严格限制在一般性的特别特定的范畴里。

换言之，我认为C++是大多数人开发大部份应用程序时的最佳选择。

14. 别人可是经常拿他们的语言与C++比来比去，这让你感到不自在了吗？

当这些比较不完整或者出於商业目的时，我确实感觉不爽。那些散布最广的比较性评论大多是由某种语言，比方说Z语言的拥护者发表的，其目的是为了证明Z比其它的语言好。由於C++被广泛地使用，所以C++通常成了黑名单上的头一个名字。通常，这类文章被夹在Z语言的供货商提供的产品之中，成了其市场竞争的一个手段。令人震惊的是，相当多的此类评论引用那些在开发Z语言的公司中工作的雇员的文章，而这些经不起考验文章无非是想证明Z是最好的。特别是在这些比较中确实有一些零零散散的事实，（所以更具欺骗性--译者），毕竟没有一种语言在任何情况下都是最好的。C++当然不完美，不过请注意，特意选择出来的事实虽然好像正确，但有时是完全的误导。

以後再看到语言比较方面的文章时，请留心是谁写的，他的表述是不是以事实为依据，以公正为准绳，特别是评判的标准是不是对於所引述的每一种语言来说都公平合理。这可不容易做到。

15. 在做小项目时，C优于C++吗？

我认为非也。除了由於缺乏好的C++编译器而导致的问题之外，我从没有看到哪个项目用C会比用C++更合适。（不过现在C++编译器导致的问题还是不可忽略的，当你看到同样功能的C++程序可执行代码体积比C大一倍而且速度慢得多时，会对此有所感触的。--译者）

以下内容来自Visual C++ Developer's Journal主编
Elden Nelson 2000年3月对B. S的专访

16.    如果您现在有机会从头设计C++语言，您会做些什麽不同的事情？

当然，你永远都不可能重新设计一种语言，那没有意义，而且任何一种语言都是它那个时代的产物。如果让我今天再设计一种语言，我仍然会综合考虑逻辑的优美 效率 通用性 实现的复杂程度和人们的喜好。要知道人们的习惯对於他们的喜好有 巨大的影响。

现在，我会寻找一种简单得多的语法，我会把类型系统的冲突问题限制在很少的几种情况里，而且你能很容易的发现这些问题。这样就能够很容易的禁止不安全的操作。（B. S的原则是：对於糟糕的代码，就算是不能完全禁止，至少也要让它大白于天下，而不是藏在阴暗的角落里暗箭伤人。C++实际上已经提供了这样的机制，例如如果你使用象reinterpret_cast(pointer)这样的很明显是非常糟糕的表达式进行造型，别人会很容易地找到问题所在。只不过C++仍然允许你使用传统的 C风格的造型机制，而又有不少人一直使用这种老式的风格，所以才引来麻烦多多。B. S的意思是说，要是现在能够禁止老式的风格该有多好 作为语言设计者的他，恐怕是没有这个机会了，但是作为语言使用者的我们，却还有很大的希望去改进自己的代码。何去何从，应该是我们深思的时候了。--译者）

我还会把核心语言的体积尽可能搞得小一些，包括类和模板的关键的抽象特性，而把很多其它的语言特性放在库里来解决。当然我也会保证核心语言足够的强大，使得那些库本身也足以用这个核心语言来产生。我可不希望标准库的创建需要用到什麽不属於该语言本身的神秘机制。另外我会让这个核心语言的定义更加精确。（有不少新的语言在建库时就使用了一些"不属於该语言本身的神秘机制"，比如VB和JAVA。从理论上讲，这是近乎无赖的行径，所以B. S不以为然。不过从实用出发倒也无伤大雅。--译者）

最重要的是，我会在该语言被广泛使用之前尽可能维持一个很长的酝酿期，这样我可以以其他人的反馈为基础进行改进。这可能是最困难的，因为一旦有什麽东西是明显出色和有前途的，大家就会蜂拥而至的来使用它，此後作任何不兼容的修正都会是非常困难的。

我相信这些思想与我当初设计C++时的理念是非常类似的，同样也是这些思想指引 一二十年来C++的不断演化。当然，我认为现在还没有什麽东西能让我觉得像是"完美的语言"。

17. 您预期C++做哪些增强，会不会删掉一些东西？

很不幸，虽然有一些东西很应该扔掉，但恐怕很难真的删掉任何东西。第一个应该抛弃的东西就是C风格的造型机制和类型截断转换。就算不禁止，编译器的作者们至少也应该对这种行为给与强烈的警告。我希望能用类似vector的东西彻底取代数组，但这显然是不可能的。不过如果程序员们能主动使用vector来代替数组，就会立刻受益匪浅。关键是你不必再使用C++中最复杂难缠的技巧了，现在有优秀得多的替代方案。

至於主要的特性，我没想去掉任何东西。特别是那些把C++与C区别开来的主要特性恐怕没法风平浪静的被抛掉。通常问这些问题的人是希望我挑出诸如多继承 异常 模板等机制来接受批判。所以在这我想大声讲清楚，我认为多继承机制对於静态类型语言实现继承性来说是必需的，异常机制是在大系统中对付错误的正确方法，模板机制是进行类型安全的 精致的和高效的程序设计的灵丹妙药。我们可以在小的细节上对於这些机制挑挑刺，但在大的方面，这些基本的概念都必须坚持。
现在我们仍在学习标准C++，也正在标准所提供的特性基础上发展出更新的 更有趣的编程技术。特别是人们刚刚开始使用STL和异常机制，还有很多高效强大的技术鲜为人知，所以大可不必急匆匆的跑去增加什麽新的机制。

我认为当前的重点是提供很多新的 比以前更加精致的 更有用的库，这方面潜力巨大。例如，如果有一个能被广泛使用的 更精致的支持并发程序设计的库，那将是一大福音--C风格的线程库（例如Pthread--译者）实在不够好。我们也就可以与各种其他的系统，例如SQL以及不同的组件模型更好地契合起来。数值计算领域的人们在这方面好像已经走在了前面，类似像Blitz++ POOMA MTL之类的高效而精致的库的开发已经取得了非凡的成就。（译者在Internet上造访了Blitz++和POOMA的主页，前者是一个高性能数学库，据称其性能与Fortran 77不相上下，同时又支持大量的C++特性。我想凡是对於数值计算领域有所了解的人都知道这有多麽伟大的意义。POOMA则是一个专门研究C++并行数学算法的项目，它的前景更加不可限量。译者非常认同B. S的这个观念。--译者）

有了足够的经验之後，我们就能更好的决定应该对标准做些什麽调整。

18. 显然，这几年世界变了，正在走向一个以Web为中心 分布式计算为主流的时代。那麽您觉得C++还能维持其地位吗？程序员们可不可能把若干种专用语言（比如Perl Javascript）综合运用以彻底取代某一种通用语言？（C++就是这样的通用语言--译者）为了配合新的计算模式，C++及其标准库应该做怎样的调整？

从来没有哪一种语言能适合所有的工作，我恐怕以後也不会有。实际系统通常是用多种语言和工具构造起来的。C++只是想成为若干语言和工具中的一个，当某些专用语言在其领域里特别突出时，它们可以与C++互为补充。也就是说，我觉得如果大多数现在的专用语言能借助特定领域的C++库共同工作的话，它们会表现得更出色。脚本语言通常导致难以维护的代码，而且也没有给程序的结构 可扩展性和可维护性的优化留下什麽余地。

我不敢肯定未来的代码是否真的会是以Web为中心的。就算是直接处理Web的系统也主要是由处理本地资源，如IP连接之类的程序模块构成的。

地理上的分布性以及服务器软件对於并发机制的高度依赖对於系统的建造者来说的确是个挑战。有些针对上述问题的库已经出现，也许我们将会看到它们最终得以标准化。当然，一些原操作和保证规则应该被加到核心语言中以提供对这些库的更佳支持。

总的来说，对於Web和网络，我们非常需要一个真正的系统/网络级的安全模型。指望JavaScript之类的脚本语言实现这个模型无异于白日做梦。

注意，我也没说C++提供了这个问题的解决方式。C++的重心是高效的访问系统资源，而不是反欺诈。

19. 您看C++未来的走向如何？在接下来的10年里它会衰落吗？或者是基本保持现在的形式？或者发展变化呈不同的形式？

C++有 最美好的未来。用它你能写出伟大的代码。除了故意进行恶意欺诈，C++仍将是开发高性能 高复杂度系统的最好语言。据我所知，没有那种语言能在通用性 效率和精致三方面的统一上可与C++相题并论。

我没看到C++有衰落的徵兆。在我能预见的未来里，它的用途还会不断增长。当然，在未来的十年里我们会看到一些变化，但不会像你想得那麽显着。跟每一种语言一样，C++也会发展变化。"语言专家们"要求改进的喧嚣声震耳欲聋，但是系统开发者们的基本请求是保持稳定。

C++会改进，但是这些改进将主要是为了反映从实践中得来的经验教训，而不会是为了追风尚赶时髦。为了更高效地使用一些新的编程技术，比如通用编程技术，可能会增加一些小的特性。会有大量的库涌现，我预期会出现一种崭新的 更出色的库支持机制。我希望新的扩展主要集中在支持抽象方面的一般特性，而不是为支持某些特殊任务的特定机制。

例如，"属性"这个概念是很有用的，但我不认为在一种通用编程语言中有它的容身之地。用标准C++的一组类可以很容易地支持这一概念。如果我们感觉那族类对於"属性"这一概念的支持不尽如人意，也不会立刻跑去在语言里增加属性机制，而是仔细考虑如何改进类和模板以帮助库设计人员尽可能接近"属性"这个概念。也许通过改进函数对象的机制能够给这个问题一个满意的答复。

为了使C++在接下来的十几年中保持灵活可变，很基本的一点就是不要让标准C++赶什麽学术或者商业的时髦。人们要求增加的特性中很大一部份通过使用现有的标准C++开发新库的方式都可以实现。还有，事实上人们渴望得到的很多特性已经被包括在标准C++中，并且被最新的编译器支持。

对许多程序员来说，提高代码质量的最佳途径不是追求什麽语言扩展，而是好好地 慢慢地品味最新的C++技术书籍（可惜我们到目前为止连这种机会都没有--译者）。

20. 您怎麽看待脚本语言的兴旺态势？特别是Python，似乎提供了一种学习OO技术的更简单的途径

有些语言很不错。比如Python，我很喜欢。但是我认为你从不同的语言中学到的OO技术是不完全相同的。当然，每一个专业的程序员都需要通晓几门语言，并且了解各种语言在编程和设计技术上的不同。

在我看来，用脚本语言建造的系统与用C++那样的通用语言建造的系统大不相同。从两类语言中学到的技术区别明显。在OO技术里也不存在什麽通用部份对於各种系统的高效建造来说都是至关重要的。

21. 有没有计划往标准C++里增加一些新的特性以支持分布式计算？

没有，我也不认为有这个必要。用更好的库就差不多能解决问题了。最多，为了支持这类的库，我们可能会增加一些低级的原操作和规则

22. 未来C++有没有可能定一个可移植的二进制接口？

如果你说的"可移植"是指跨硬件和块操作系统的可移植，我想回答是不会。我们当然可以设计一个解释器或者虚拟机（如同Java的做法--译者），但这样一来，由於无法以最优的方式访问系统资源，C++的能力就会受到削弱，。我真正希望在不远的将来能够看见的东西是platform ABIs（ABI， Application Binary Interface） 。例如，有人正在努力为Intel新的IA64体系定义C++ ABI，我想这些努力会得到用户们的巨大支持。能够把不同编译器产生的代码编译在一起将会是一项十分有意义的事情。

23. 在不少流行领域，C++正在渐渐失去光芒，因为它要求人们花很大的精力去对付一些很基本的工作，比如管理内存（因为没有垃圾收集机制），管理模块之间的依赖性（因为没有包机制），管理组件的版本。C++缺乏一些现代语言已经视为标准的特性。比如传言中最酷的Java语言就特别重视这些问题。那麽在解决这些问题是否会导致C++的发展背离其根本宗旨呢？C++应该怎样发展以保证我们在这种语言上的投资能有合理的回报，而不是被迫去重新使用另一种语言？

我倒还没有注意到C++比以前用的少了。相反，我看到的指标表明C+的使用还在稳定地增长 。只不过这种基数很大的稳定增长以及在标准性 移植性和库方面的不断提高并没有造成什麽具有欺骗性的新闻效应而已。我认为你所说的"失去光芒"只不过是市场推销和新闻意义上的现象。

如果你需要垃圾收集机制的话，你可以在C++应用程序中插入一个垃圾收集器。有不少自由的和商业的垃圾收集器已经在重要的实践中被证明是很出色的。

如果你不想使用垃圾收集机制，也没关系。你可以使用标准容器类，它们大大减少了对於显式分配和回收内存的需要。这样，使用现代的库和现代的编程风格，你能够避免大部份的内存管理问题。

同样的技术还能够用来避免一般资源的管理问题。并不是只有内存才会泄漏，线程句柄 文件 互斥锁 网络连接等都是重要的资源，为了建立可靠的系统，这些资源必须被正确的管理。如果你觉得有了垃圾收集机制就可以解决所有的资源管理问题，那麽你最好赶快从美梦中醒来。

C++提供了很多机制来管理一般性的资源。关键的手段--"Resource Acquisition is Initialization"(这是著名的RAII惯用法，阅读原文时会经常遇到，其意义是说将所有的资源分配申请放在对象初始化过程中进行，而将资源释放动作放在对象销毁过程中——译者)可以使用函数对象来管理生存期问题。语言中关於对象的局部构造和异常机制对这项技术提供了支持。

某些语言的狂热支持者总是用讽刺漫画的笔法描述C++，然而C++实际上要好得多。特别是我觉得很多其他的特性已经泛滥不堪了，在C++中，通常这些特性能够很容易的被模拟出来。相反的，新的语言在推广的过程中总是不断地增加新的特性，这就是为什麽从一种语言诞生到被广泛使用，其体积通常会增加个两三倍。

目前，最为个人和组织，对於C++的最好投资就是去更好地理解标准C++和现代的C++设计编程技术。大多数人使用C++的方式实际上停留80年代中期的水平，甚至比那更陈旧。

至於模块依赖性问题，我的观点是，在编程语言的工作和系统的工作之间应该有一个明显的界线，依赖关系应该尽可能地与编程语言分开，而由系统来支持。

我不认为组建版本的问题应该由编程语言来解决，这是一个系统范畴里的问题，在语言里应该通过提供相应的库来解决。C++有这样的机制。

解决这样的问题不会使C++偏离轨道。但是给C++增加很多特殊的特性就会使C++偏离轨道，而且在保持可移植性和平台独立性方面也会是一个倒退。

24. 标准C++推出有段时间了，Java也大踏步地往前走而且取得了显着的进步，您现在怎麽比较Java与C++？您觉得Java想要变成像C++一样"好"的语言还需要做些什麽？您举的C++从Java身上学到了什麽经验吗？有没有什麽Java的特性您认为是可以被C++吸纳的？

我不比较语言。做好这项工作是十分困难的，而且很少具有专业水准。

我认为C++的进步会是主要以它的用户在使用中遇到的问题以及其自身逻辑为基础。当然，其他语言中的某些思想也会被考虑，但不能被简单的移花接木过来。你必须审视那些机制在技术上和思想上的背景，并且找到在C++中支持这些技术的最佳方案。

有时最好的选择是综合使用几种语言。毕竟没有任何一种语言是放之四海而皆优的。C++现在是，将来也继续会是在广泛应用领域中最好的语言之一。但是，我们不能被拉下水，不能把所有可能的特性都加到C++里面来向大众献媚。我认为Java和C++现在和将来都会是十分不同的语言，语法相似，但背後的对象模型明显不同。

对於我来说，一个很重要的区别是C++有一个ISO标准，而Java则是一个专有语言。

25. 在Java刚刚出现的那几年，有很多欺骗性的言论说它将会是终极语言，会取代C++。您觉得在过去两三年里Java对C++的追随者们有什麽影响？

到现在关於Java的不实之辞也还随处可见。暂且不提Java在过去5年间的创纪录的发展，狂热的大众似乎认为Java将最终取代的不仅仅是C++，而且还有所有其他的编程语言。但在另一方面，C++的使用仍在继续增长。我不认为Java对於C++的影响已经使得人们转而把本来打算用来创造更好的C++工具库的资源调过去开发Java工具库。Java对於学习编程的人来说没有太多的新东西，所以对於C++的定义也没什麽影响。在那个领域，Java还得努力追赶。例如，我认为为Sun迟早会往Java里加入类似模板的机制。

人们应该认识到C++和Java的目标是何等的不同。 以C++的设计理念来衡量Java，或是以Java的设计理念来衡量C++，得出的结论都不会很好。

在访谈即将结束时，或许我该再次表明态度：C++仍然是我喜爱的语言，在写代码时你会发现没有那种语言能像它那样在如此广泛的应用领域和平台上同时达成如此的高效与精致。

以下内容选自B. S在自己主页上发表的FAQ

1. 请谈谈C++书。

没有，也不可能有一本书对於所有人来说都是最好的。不过对於那些真正的程序员来说，如果他喜欢从"经典风格"的书中间学习一些新的概念和技术，我推荐我的The C++ Programming Language, 1998年的第三版和特别版。那本书讲的是纯而又纯的C++，完全独立於平台和库（当然得讲到标准库）。该书面向那些有一定经验的程序员，帮助他们掌握C++，但不适合毫无经验的初学者入门，也不适合那些临时程序员品尝C++快餐。所以这本书的重点在於概念和技术，而且在完整性和精确性上下了不少功夫。如果你想知道为什麽C++会变成今天的模样，我的另一本书 The Design and Evolution of C++ 能给你满意的答案。理解设计的原则和限制能帮助你写出更好的程序。www.accu.org是最好的书评网站之一，很多有经验的程序员在此仗义执言，不妨去看看。

2. 学习C++要花多长时间？

这要看你说的"学习"是什麽意思了。如果你是一个Pascal程序员，你应该能很快地使你的C++水平达到与Pascal相近的程度；而如果你是一个C程序员，一天之内你就能学会使用C++进行更出色的C风格编程。另一方面，如果你想完全掌握C++的主要机制，例如数据抽象，面向对象编程，通用编程，面向对象设计等等，而此前又对这些东西不很熟悉的话，花上个一两年是不足为奇的。那麽是不是说这就是学习C++所需要的时间呢？也许再翻一番，我想打算成为更出色的设计师和程序员最起码也要这麽长的时间。如果学习一种新的语言不能使我们的工作和思想方式发生深刻
的变革，那又何苦来哉？跟成为一个钢琴家或者熟练掌握一门外语相比，学习一种新的 不同的语言和编程风格还算是简单的。

3. 了解C是学习C++的先决条件吗？

否 C++中与C相近的子集其实比C语言本身要好学，类型方面的错误会少一些，也不像C那样绕圈子，还有更好的支持库。所以应该从这个子集开始学习C++。

4. 要想成为真正的OO程序员，我是不是得先学习Smalltalk？

否。如果你想学Smalltaok，尽管去学。这种语言很有趣，而且学习新东西总是一个好主意。但是Smalltalk不是C++，而且把Smalltalk的编程风格用在C++里不会有什麽好结果。如果你想成为一个出色的C++程序员，而且也没有几个月的时间百无聊赖，请你集中力量学好C++以及其背後的思想。

5. 我如何开始学习C++？

这取决于你的基础和学习动机。如果你是个初学者，我想你最好找个有经验的程序员来帮助你，要不然你在学习和实践中不可避免的犯下的种种错误会大大地打击你的积极性。另外，即使你的编译器配备了充足的文档资料，一本C++书籍也永远是必不可少的，毕竟文档资料不是学习编程思想的好教材。

选择书籍时，务必注意该书是不是从一开始就讲授标准C++，并且矢志不渝地使用标准库机制。例如，从输入中读取一个字符串应该是这样的：

    string s;    // Standard C++ style
    cin >> s;

而不是这样的：

    char s[MAX];    /* Standard C style */
    scanf("%s",s);

去看看那些扎实的C++程序员们推荐的书吧。记住，没有哪本书对所有人来说都是最好的。另外，要写地道的C++程序，而避免用C++的语法写传统风格的程序，新瓶装旧酒没多大意义。（遗憾的是，目前在市面上的中文C++教材中，符合B. S的这个标准的可以说一本都没有，大家只好到网上找一些英文的资料来学习了。--译者）

6. 怎样改进我的C++程序？

不好说。这取决于你是怎麽使用该语言的。大多数人低估了抽象类和模板的价值，反过来却肆无忌惮地使用造型机制(cast)和宏。这方面可以看看我的文章和书。抽象类和和模板的作用当然是提供一种方便的手段建构单根的类层次或者重用函数，但更重要的是，它们作为接口提供了简洁的 逻辑性的服务表示机制。

7. 语言的选择是不是很重要？

是，但也别指望奇迹。很多人似乎相信某一种语言能够解决他们在系统开发中遇到的几乎所有问题，他们不断地去寻找完美的编程语言，然後一次次的失败，一次次的沮丧。另外一些人则将编程语言贬为无关紧要的细节，把大把大把的银子放在开发流程和设计方法上，他们永远都在用COBOL C和一些专有语言。一种优秀的语言，例如C++，能帮助设计者和程序员做很多事情，而其能力和缺陷又能够被清楚地了解和对待。

8. ANSI/ISO标准委员会是不是糟蹋了C++？

当然不是 他们（我们）的工作很出色。你可以在一些细节上找些歪理来挑刺，但我个人对於这种语言以及新的标准库可是欣欣然。ISO C++较之C++的以前版本更出色更有条理。相对於标准化过程刚刚开始之初，你今天可以写出更优雅 更易于维护的C++程序。新的标准库也是一份真正的大礼。由於标准库提供了strings, lists, vectors, maps以及作用于其上的基本算法，使用C++的方式已经发生了巨大的变化。

9. 你现在有没有想删除一些C++特性？

没有，真的。问这些问题的人大概是希望我回答下面特性中的一个：多继承 异常 模板和RTTI。但是没有它们，C++就是不完整的。在过去的N年中，我已经反复考虑过它们的设计，并且与标准委员会一起改进了其细节，但是没有一个能被去掉又不引起大地震。

从语言设计的角度讲，我最不喜欢的部份是与C兼容的那个子集，但又不能把它去掉，因为那样对於在现实世界里工作的程序员们来说伤害太大了。C++与C兼容，这是一项关键的设计决策，绝对不是一个叫卖的噱头。兼容性的实现和维护是十分困难的，但确实使程序员们至今受益良多。

但是现在，C++已经有了新的特性，程序员们可以从麻烦多多的C风格中解脱出来。例如，使用标准库里的容器类，象vector, list, map, string等等，可以避免与底层的指针操作技巧混战不休。

10. 如果不必和C兼容，你所创造的语言是不是就会是Java?

不是，差得远。如果人们非要拿C++和Java来作比较，我建议他们去阅读The Design and Evolution of C++，看看C++为什麽是今天这个样子，用我在设计C++时遵从的原则来检验这两种语言。这些原则与SUN的Java开发小组所持的理念显然是不同的。除了表面语法的相似性之外，C++与Java是截然不同的语言。在很多方面，Java更像Smalltalk（译者按：我学习Java时用的是Sun的培训教材，里面清楚地写道：Java在设计上采用了与C++相似的语法，与Smalltalk相似的语义。所以可以说Java与C++是貌合神离，与Smalltalk才是心有灵犀）。Java语言相对简单，这部分是一种错觉，部份是因为这种语言还不完整。随 时间的推移，Java在体积和复杂程度上都会大大增长。在体积上它会增长两到三倍，而且会出现一些实现相关的扩展或者库。这是一条每个成功的商业语言都必须走过的发展之路。随便分析一种你认为在很大范围内取得了成功的语言，我知道肯定是无有例外者，而且实际上这非常有道理。

上边这段话是在Java 1.1推出之前写的。我确信Java需要类似模板的机制，并且需要增强对於固有类型的支持。简单地说，就是为了基本的完整性也应该做这些工作。另外还需要做很多小的改动，大部份是扩展。1998年秋，我从James Gosling（Java语言的创始人--译者）那里得到一份建议书，说是要在Java中增加固有类型 操作符重载以及数学计算支持。还有一篇论文，是数学分析领域的世界级大师，伯克利大学的W. Kahan教授所写的How Java's Floating-Point Hurts Everyone Everywhere（"且看Java的浮点运算如何危害了普天下的芸芸众生"--译者），揭露了Java的一些秘密。

我发现在电视和出版物中关於Java的鼓吹是不准确的，而且气势汹汹，让人讨厌。大肆叫嚣凡是非Java的代码都是垃圾，这是对程序员的侮辱；建议把所有的保留代码都用Java重写，这是丧心病狂，既不现实也不负责任。Sun和他的追随者似乎觉得为了对付微软罪恶的"帝国时代"，就必须如此自吹自擂。但是侮辱和欺诈只会把那些喜欢使用不同编程语言的程序员逼到微软阵营里去。

Java并非平台无关，它本身就是平台。跟Windows一样，它也是一个专有的商业平台。也就是说，你可以为Windows/Intel编写代码，也可以为Java/JVM编写代码，在任何一种情况下，你都是在为一个属於某个公司的平台写代码，这些代码都是与该公司的商业利益扯在一起的。当然你可以使用任何一种语言，结合操作系统的机制来编写可供JVM执行的程序，但是JVM之类的东西是强烈地偏向于Java语言的。它一点也不像是通用的 公平的 语言中立的VM/OS。

私下里，我会坚持使用可移植的C++作大部份工作，用不同的语言作余下的工作。
（"Java is not platform-independent, it is the platform"，B. S的这句评语对於C++用户有 很大的影响，译者在国外的几个新闻组里看到，有些C++高手甚至把这句话作为自己的签名档，以表明对Java的态度和誓死捍卫C++的决心。实际上有很多程序员不光是把自己喜爱的语言当成一种工具，更当成一种信仰。--译者）

11. 您怎麽看待C#语言？

就C#语言本身我没什麽好说的。想让我相信这个世界还需要另外一个专有的语言可不是一件容易的事，而且这个语言还是专门针对某一个专有操作系统的，这就更让我难以接受。直截了当地说，我不是一个专有语言的痴迷者，而是一个开放的正式标准的拥护者。

12. 在做大项目时，您是不是真的推荐Ada，而不是C++？

当然不是。我不知道这是谁传出来的谣言，肯定是一个Ada信徒，要麽是过份狂热，要麽是不怀好意。

13. 你愿不愿意将C++与别的语言比较？

抱歉，我不愿意。你可以在The Design and Evolution of C++的介绍性文字里找到原因。

有不少书评家邀请我把C++与其它的语言相比，我已经决定不做此类事情。在此我想重申一个我很久以来一直强调的观点：语言之间的比较没什麽意义，更不公平。主流语言之间的合理比较要耗费很大的精力，多数人不会愿意付出这麽大的代价。另外还需要在广泛的应用领域有充份经验，保持一种不偏不倚 客观独立的立场，有 公正无私的信念。我没时间，而且作为C++的创造者，在公正无私这一点上我永远不会获得完全的信任。

人们试图把各种语言拿来比较长短，有些现像我已经一次又一次地注意到，坦率地说我感到担 。作者们尽力表现的公正无私，但是最终都是无可救药地偏向于某一种特定的应用程序，某一种特定的编程风格，或者某一种特定的程序员文化。更糟的是，当某一种语言明显地比另一种语言更出名时，一些不易察觉的偷梁换柱就开始了：比较有名的语言中的缺陷被有意淡化，而且被拐弯抹角地加以掩饰；而同样的缺陷在不那麽出名的语言里就被描述为致命硬伤。类似的，有关比较出名的语言的技术资料经常更新，而不太出名的语言的技术资料往往是几年以前的，试问这种比较有何公正性和意义可言？所以我对於C++之外的语言的评论严格限制在一般性的特别特定的范畴里。

换言之，我认为C++是大多数人开发大部份应用程序时的最佳选择。

14. 别人可是经常拿他们的语言与C++比来比去，这让你感到不自在了吗？

当这些比较不完整或者出於商业目的时，我确实感觉不爽。那些散布最广的比较性评论大多是由某种语言，比方说Z语言的拥护者发表的，其目的是为了证明Z比其它的语言好。由於C++被广泛地使用，所以C++通常成了黑名单上的头一个名字。通常，这类文章被夹在Z语言的供货商提供的产品之中，成了其市场竞争的一个手段。令人震惊的是，相当多的此类评论引用那些在开发Z语言的公司中工作的雇员的文章，而这些经不起考验文章无非是想证明Z是最好的。特别是在这些比较中确实有一些零零散散的事实，（所以更具欺骗性--译者），毕竟没有一种语言在任何情况下都是最好的。C++当然不完美，不过请注意，特意选择出来的事实虽然好像正确，但有时是完全的误导。

以後再看到语言比较方面的文章时，请留心是谁写的，他的表述是不是以事实为依据，以公正为准绳，特别是评判的标准是不是对於所引述的每一种语言来说都公平合理。这可不容易做到。

15. 在做小项目时，C优于C++吗？

我认为非也。除了由於缺乏好的C++编译器而导致的问题之外，我从没有看到哪个项目用C会比用C++更合适。（不过现在C++编译器导致的问题还是不可忽略的，当你看到同样功能的C++程序可执行代码体积比C大一倍而且速度慢得多时，会对此有所感触的。--译者）

以下内容来自Visual C++ Developer's Journal主编
Elden Nelson 2000年3月对B. S的专访

16.    如果您现在有机会从头设计C++语言，您会做些什麽不同的事情？

当然，你永远都不可能重新设计一种语言，那没有意义，而且任何一种语言都是它那个时代的产物。如果让我今天再设计一种语言，我仍然会综合考虑逻辑的优美 效率 通用性 实现的复杂程度和人们的喜好。要知道人们的习惯对於他们的喜好有 巨大的影响。

现在，我会寻找一种简单得多的语法，我会把类型系统的冲突问题限制在很少的几种情况里，而且你能很容易的发现这些问题。这样就能够很容易的禁止不安全的操作。（B. S的原则是：对於糟糕的代码，就算是不能完全禁止，至少也要让它大白于天下，而不是藏在阴暗的角落里暗箭伤人。C++实际上已经提供了这样的机制，例如如果你使用象reinterpret_cast(pointer)这样的很明显是非常糟糕的表达式进行造型，别人会很容易地找到问题所在。只不过C++仍然允许你使用传统的 C风格的造型机制，而又有不少人一直使用这种老式的风格，所以才引来麻烦多多。B. S的意思是说，要是现在能够禁止老式的风格该有多好 作为语言设计者的他，恐怕是没有这个机会了，但是作为语言使用者的我们，却还有很大的希望去改进自己的代码。何去何从，应该是我们深思的时候了。--译者）

我还会把核心语言的体积尽可能搞得小一些，包括类和模板的关键的抽象特性，而把很多其它的语言特性放在库里来解决。当然我也会保证核心语言足够的强大，使得那些库本身也足以用这个核心语言来产生。我可不希望标准库的创建需要用到什麽不属於该语言本身的神秘机制。另外我会让这个核心语言的定义更加精确。（有不少新的语言在建库时就使用了一些"不属於该语言本身的神秘机制"，比如VB和JAVA。从理论上讲，这是近乎无赖的行径，所以B. S不以为然。不过从实用出发倒也无伤大雅。--译者）

最重要的是，我会在该语言被广泛使用之前尽可能维持一个很长的酝酿期，这样我可以以其他人的反馈为基础进行改进。这可能是最困难的，因为一旦有什麽东西是明显出色和有前途的，大家就会蜂拥而至的来使用它，此後作任何不兼容的修正都会是非常困难的。

我相信这些思想与我当初设计C++时的理念是非常类似的，同样也是这些思想指引 一二十年来C++的不断演化。当然，我认为现在还没有什麽东西能让我觉得像是"完美的语言"。

17. 您预期C++做哪些增强，会不会删掉一些东西？

很不幸，虽然有一些东西很应该扔掉，但恐怕很难真的删掉任何东西。第一个应该抛弃的东西就是C风格的造型机制和类型截断转换。就算不禁止，编译器的作者们至少也应该对这种行为给与强烈的警告。我希望能用类似vector的东西彻底取代数组，但这显然是不可能的。不过如果程序员们能主动使用vector来代替数组，就会立刻受益匪浅。关键是你不必再使用C++中最复杂难缠的技巧了，现在有优秀得多的替代方案。

至於主要的特性，我没想去掉任何东西。特别是那些把C++与C区别开来的主要特性恐怕没法风平浪静的被抛掉。通常问这些问题的人是希望我挑出诸如多继承 异常 模板等机制来接受批判。所以在这我想大声讲清楚，我认为多继承机制对於静态类型语言实现继承性来说是必需的，异常机制是在大系统中对付错误的正确方法，模板机制是进行类型安全的 精致的和高效的程序设计的灵丹妙药。我们可以在小的细节上对於这些机制挑挑刺，但在大的方面，这些基本的概念都必须坚持。
现在我们仍在学习标准C++，也正在标准所提供的特性基础上发展出更新的 更有趣的编程技术。特别是人们刚刚开始使用STL和异常机制，还有很多高效强大的技术鲜为人知，所以大可不必急匆匆的跑去增加什麽新的机制。

我认为当前的重点是提供很多新的 比以前更加精致的 更有用的库，这方面潜力巨大。例如，如果有一个能被广泛使用的 更精致的支持并发程序设计的库，那将是一大福音--C风格的线程库（例如Pthread--译者）实在不够好。我们也就可以与各种其他的系统，例如SQL以及不同的组件模型更好地契合起来。数值计算领域的人们在这方面好像已经走在了前面，类似像Blitz++ POOMA MTL之类的高效而精致的库的开发已经取得了非凡的成就。（译者在Internet上造访了Blitz++和POOMA的主页，前者是一个高性能数学库，据称其性能与Fortran 77不相上下，同时又支持大量的C++特性。我想凡是对於数值计算领域有所了解的人都知道这有多麽伟大的意义。POOMA则是一个专门研究C++并行数学算法的项目，它的前景更加不可限量。译者非常认同B. S的这个观念。--译者）

有了足够的经验之後，我们就能更好的决定应该对标准做些什麽调整。

18. 显然，这几年世界变了，正在走向一个以Web为中心 分布式计算为主流的时代。那麽您觉得C++还能维持其地位吗？程序员们可不可能把若干种专用语言（比如Perl Javascript）综合运用以彻底取代某一种通用语言？（C++就是这样的通用语言--译者）为了配合新的计算模式，C++及其标准库应该做怎样的调整？

从来没有哪一种语言能适合所有的工作，我恐怕以後也不会有。实际系统通常是用多种语言和工具构造起来的。C++只是想成为若干语言和工具中的一个，当某些专用语言在其领域里特别突出时，它们可以与C++互为补充。也就是说，我觉得如果大多数现在的专用语言能借助特定领域的C++库共同工作的话，它们会表现得更出色。脚本语言通常导致难以维护的代码，而且也没有给程序的结构 可扩展性和可维护性的优化留下什麽余地。

我不敢肯定未来的代码是否真的会是以Web为中心的。就算是直接处理Web的系统也主要是由处理本地资源，如IP连接之类的程序模块构成的。

地理上的分布性以及服务器软件对於并发机制的高度依赖对於系统的建造者来说的确是个挑战。有些针对上述问题的库已经出现，也许我们将会看到它们最终得以标准化。当然，一些原操作和保证规则应该被加到核心语言中以提供对这些库的更佳支持。

总的来说，对於Web和网络，我们非常需要一个真正的系统/网络级的安全模型。指望JavaScript之类的脚本语言实现这个模型无异于白日做梦。

注意，我也没说C++提供了这个问题的解决方式。C++的重心是高效的访问系统资源，而不是反欺诈。

19. 您看C++未来的走向如何？在接下来的10年里它会衰落吗？或者是基本保持现在的形式？或者发展变化呈不同的形式？

C++有 最美好的未来。用它你能写出伟大的代码。除了故意进行恶意欺诈，C++仍将是开发高性能 高复杂度系统的最好语言。据我所知，没有那种语言能在通用性 效率和精致三方面的统一上可与C++相题并论。

我没看到C++有衰落的徵兆。在我能预见的未来里，它的用途还会不断增长。当然，在未来的十年里我们会看到一些变化，但不会像你想得那麽显着。跟每一种语言一样，C++也会发展变化。"语言专家们"要求改进的喧嚣声震耳欲聋，但是系统开发者们的基本请求是保持稳定。

C++会改进，但是这些改进将主要是为了反映从实践中得来的经验教训，而不会是为了追风尚赶时髦。为了更高效地使用一些新的编程技术，比如通用编程技术，可能会增加一些小的特性。会有大量的库涌现，我预期会出现一种崭新的 更出色的库支持机制。我希望新的扩展主要集中在支持抽象方面的一般特性，而不是为支持某些特殊任务的特定机制。

例如，"属性"这个概念是很有用的，但我不认为在一种通用编程语言中有它的容身之地。用标准C++的一组类可以很容易地支持这一概念。如果我们感觉那族类对於"属性"这一概念的支持不尽如人意，也不会立刻跑去在语言里增加属性机制，而是仔细考虑如何改进类和模板以帮助库设计人员尽可能接近"属性"这个概念。也许通过改进函数对象的机制能够给这个问题一个满意的答复。

为了使C++在接下来的十几年中保持灵活可变，很基本的一点就是不要让标准C++赶什麽学术或者商业的时髦。人们要求增加的特性中很大一部份通过使用现有的标准C++开发新库的方式都可以实现。还有，事实上人们渴望得到的很多特性已经被包括在标准C++中，并且被最新的编译器支持。

对许多程序员来说，提高代码质量的最佳途径不是追求什麽语言扩展，而是好好地 慢慢地品味最新的C++技术书籍（可惜我们到目前为止连这种机会都没有--译者）。

20. 您怎麽看待脚本语言的兴旺态势？特别是Python，似乎提供了一种学习OO技术的更简单的途径

有些语言很不错。比如Python，我很喜欢。但是我认为你从不同的语言中学到的OO技术是不完全相同的。当然，每一个专业的程序员都需要通晓几门语言，并且了解各种语言在编程和设计技术上的不同。

在我看来，用脚本语言建造的系统与用C++那样的通用语言建造的系统大不相同。从两类语言中学到的技术区别明显。在OO技术里也不存在什麽通用部份对於各种系统的高效建造来说都是至关重要的。

21. 有没有计划往标准C++里增加一些新的特性以支持分布式计算？

没有，我也不认为有这个必要。用更好的库就差不多能解决问题了。最多，为了支持这类的库，我们可能会增加一些低级的原操作和规则

22. 未来C++有没有可能定一个可移植的二进制接口？

如果你说的"可移植"是指跨硬件和块操作系统的可移植，我想回答是不会。我们当然可以设计一个解释器或者虚拟机（如同Java的做法--译者），但这样一来，由於无法以最优的方式访问系统资源，C++的能力就会受到削弱，。我真正希望在不远的将来能够看见的东西是platform ABIs（ABI， Application Binary Interface） 。例如，有人正在努力为Intel新的IA64体系定义C++ ABI，我想这些努力会得到用户们的巨大支持。能够把不同编译器产生的代码编译在一起将会是一项十分有意义的事情。

23. 在不少流行领域，C++正在渐渐失去光芒，因为它要求人们花很大的精力去对付一些很基本的工作，比如管理内存（因为没有垃圾收集机制），管理模块之间的依赖性（因为没有包机制），管理组件的版本。C++缺乏一些现代语言已经视为标准的特性。比如传言中最酷的Java语言就特别重视这些问题。那麽在解决这些问题是否会导致C++的发展背离其根本宗旨呢？C++应该怎样发展以保证我们在这种语言上的投资能有合理的回报，而不是被迫去重新使用另一种语言？

我倒还没有注意到C++比以前用的少了。相反，我看到的指标表明C+的使用还在稳定地增长 。只不过这种基数很大的稳定增长以及在标准性 移植性和库方面的不断提高并没有造成什麽具有欺骗性的新闻效应而已。我认为你所说的"失去光芒"只不过是市场推销和新闻意义上的现象。

如果你需要垃圾收集机制的话，你可以在C++应用程序中插入一个垃圾收集器。有不少自由的和商业的垃圾收集器已经在重要的实践中被证明是很出色的。

如果你不想使用垃圾收集机制，也没关系。你可以使用标准容器类，它们大大减少了对於显式分配和回收内存的需要。这样，使用现代的库和现代的编程风格，你能够避免大部份的内存管理问题。

同样的技术还能够用来避免一般资源的管理问题。并不是只有内存才会泄漏，线程句柄 文件 互斥锁 网络连接等都是重要的资源，为了建立可靠的系统，这些资源必须被正确的管理。如果你觉得有了垃圾收集机制就可以解决所有的资源管理问题，那麽你最好赶快从美梦中醒来。

C++提供了很多机制来管理一般性的资源。关键的手段--"Resource Acquisition is Initialization"(这是著名的RAII惯用法，阅读原文时会经常遇到，其意义是说将所有的资源分配申请放在对象初始化过程中进行，而将资源释放动作放在对象销毁过程中——译者)可以使用函数对象来管理生存期问题。语言中关於对象的局部构造和异常机制对这项技术提供了支持。

某些语言的狂热支持者总是用讽刺漫画的笔法描述C++，然而C++实际上要好得多。特别是我觉得很多其他的特性已经泛滥不堪了，在C++中，通常这些特性能够很容易的被模拟出来。相反的，新的语言在推广的过程中总是不断地增加新的特性，这就是为什麽从一种语言诞生到被广泛使用，其体积通常会增加个两三倍。

目前，最为个人和组织，对於C++的最好投资就是去更好地理解标准C++和现代的C++设计编程技术。大多数人使用C++的方式实际上停留80年代中期的水平，甚至比那更陈旧。

至於模块依赖性问题，我的观点是，在编程语言的工作和系统的工作之间应该有一个明显的界线，依赖关系应该尽可能地与编程语言分开，而由系统来支持。

我不认为组建版本的问题应该由编程语言来解决，这是一个系统范畴里的问题，在语言里应该通过提供相应的库来解决。C++有这样的机制。

解决这样的问题不会使C++偏离轨道。但是给C++增加很多特殊的特性就会使C++偏离轨道，而且在保持可移植性和平台独立性方面也会是一个倒退。

24. 标准C++推出有段时间了，Java也大踏步地往前走而且取得了显着的进步，您现在怎麽比较Java与C++？您觉得Java想要变成像C++一样"好"的语言还需要做些什麽？您举的C++从Java身上学到了什麽经验吗？有没有什麽Java的特性您认为是可以被C++吸纳的？

我不比较语言。做好这项工作是十分困难的，而且很少具有专业水准。

我认为C++的进步会是主要以它的用户在使用中遇到的问题以及其自身逻辑为基础。当然，其他语言中的某些思想也会被考虑，但不能被简单的移花接木过来。你必须审视那些机制在技术上和思想上的背景，并且找到在C++中支持这些技术的最佳方案。

有时最好的选择是综合使用几种语言。毕竟没有任何一种语言是放之四海而皆优的。C++现在是，将来也继续会是在广泛应用领域中最好的语言之一。但是，我们不能被拉下水，不能把所有可能的特性都加到C++里面来向大众献媚。我认为Java和C++现在和将来都会是十分不同的语言，语法相似，但背後的对象模型明显不同。

对於我来说，一个很重要的区别是C++有一个ISO标准，而Java则是一个专有语言。

25. 在Java刚刚出现的那几年，有很多欺骗性的言论说它将会是终极语言，会取代C++。您觉得在过去两三年里Java对C++的追随者们有什麽影响？

到现在关於Java的不实之辞也还随处可见。暂且不提Java在过去5年间的创纪录的发展，狂热的大众似乎认为Java将最终取代的不仅仅是C++，而且还有所有其他的编程语言。但在另一方面，C++的使用仍在继续增长。我不认为Java对於C++的影响已经使得人们转而把本来打算用来创造更好的C++工具库的资源调过去开发Java工具库。Java对於学习编程的人来说没有太多的新东西，所以对於C++的定义也没什麽影响。在那个领域，Java还得努力追赶。例如，我认为为Sun迟早会往Java里加入类似模板的机制。

人们应该认识到C++和Java的目标是何等的不同。 以C++的设计理念来衡量Java，或是以Java的设计理念来衡量C++，得出的结论都不会很好。

在访谈即将结束时，或许我该再次表明态度：C++仍然是我喜爱的语言，在写代码时你会发现没有那种语言能像它那样在如此广泛的应用领域和平台上同时达成如此的高效与精致。

·类机制（封装与模板）

·异常

·内存— 重点

·大型文件的随机访问

·资源获取初始化

正如我在第一部分提到的，这里所做的测试只是针对程序性能的一小部分，硬件及操作系统的配置是测试语言 /编译器/库函数的机器的典型配置：2-GHZ，512-MB，Pentium IV，Windows XP Professional。 这里我们看到的任何结果揭示了在其它环境下可能的性能，这不说明可以假设这些结果就是正确的典型例子。 最后要说明的是，当我提到“C#比Java好”等结论的时候，一定是指“在特定的测试环境的条件下”，这一点请你铭记在心。

性能评价

所有的代码还是用和第一部分一样的编译器编译。 C#代码在.NET框架 1.0.3705（可从http://microsoft.com/netframework/免费下载）下，由Visual C#.NET 编译器v7.00.9466编译。D代码由Digital Mars D 编译器 Alpha v0.62 (可从http://www.digitalmars.com/免费下载) 编译。Java代码由J2DKSE1.4.1-02 ( 可免费下载 http://java.sun.com/ ) 编译。 C和C++代码 ( 单线程 , 包括 raii , 和静态链接库 ) 由使用 STLPort v4.5的Digital Mars C/C++ v8.33 ( 可从 http://www.digitalmars.com/免费下载 ) 和使用 Visual C++ 6.0的头文件和库文件的Intel C/C++ v7.0来编译。所有这些编译器均使用最优化处理 ( set for speed ) ; Intel 用-QaxW flag [2]提供两套编码路径：一个是针对有SSE2的Pentium IV处理器，另一个是针对其他所有的处理器——在运行时选择合适的一个。（因为Intel编译器只适用于Intel处理器构造，特别是在这个测试中的Pentium IV，这编译器的编译结果必须在此基础上评价，不能在其他的处理器上进行同样的过程，比如Athlon，甚至是旧版本的Intel处理器也不行。）

后面将要描述我们测试的假想的五种例子中的性能表现。他们都用2-GHZ，512-MB，Pentium IV，Windows XP Professional的配置，并沿用在第一部分用的性能分析系统。每一种语言所编程序的调试都执行7次，同时没有其他占线过程，去掉最高速的和最低速的，纪录平均值。所有的时间信息，通过仅区分相应时间区间的高性能计时器保存下来。（C用户调用Win32 API QueryPerformanceCounter() ；C++ 用 Win-STL ' s performance_counter [4], 可在http://winstl.org/找到 ； C# 用 SynSoft.Performance.PerformanceCounter ，可在 http://synsoft.org/dotnet.html找到； D 用 synsoft.win32.perf.PerformanceCounter , 可在http://synsoft.org/d.html找到；Java 用 System.currentTimeMillis() .）每一个测试程序都包含一个启动迭代的程序，这样可以将启动或缓冲时的影响最小化。

在每一个例子中的C#，C++和D的特征: C在所有 保存 封装和 raii( 类)的地方出现，因为它没有这两种例子必需的语言特征。 raii 没有出现Java，因为Java甚至连 Resource AcquisitionIs Initialization (RAII [1])的机制也没有，所以它仅仅作为在GC-kicking的一个练习。简单的说，我不会展示所有的语言的每一个例子的所有特性，但是所有这些都包含于在线记录中（连同产生他们的Digital Mars make-compatible make-file）。

下面就对测试性能的例子进行评价 :

封装 。这个例子（ Listing1）的目的是比较不同语言（除了C）在类机制上的代价，这些语言并不完全支持相对于它们所做的所有类型的一般处理。尤其是C#和Java一般不能存储和使用它们的内置类型实例，比如int，long，bool等等，同样，对于从这些实例派生的类型也不行。相反C++和D都支持模板，它可以给任何类型的一般性操作带来方便。在以后的文章里，我将详细地讲解容器。但在这个章节将不会用到它，如果提及它反而会分散对于封装意义的理解。C#和Java中未封装的变量传递ints给异或函数，封装变量传递整形值在Int32（C#）和Interger（Java）的实例中。注意Java不支持模糊的封装（这被证明是好的因为编译器将对于这种封装带来的低效给予警告），所以实例必须明确地被创建（在列表1中标记“Java ” 处可以看到）。 C++和D的运行是简单的使用模板，这就是它们的泛型机制。（在这里我不对“一切都是对象”的模板的好处作深入探讨，但是我将在这期的姊妹篇Stepanov camp中对它做详细讲解）。

异常处理 。异常的语义在各种语言之间有很大的区别。 在 C++，异常处理和调用析构函数一起沿着堆栈操作下来，然而在有垃圾回收的语言中，这些对象被丢弃，直到将来的某一时刻被收集。 这样，就无法对各种语言进行有意义的比较。所以在这个例子中，只能通过将一段 using/aware代码与另一段没有异常处理支持的相同代码进行比较。这个例子有三种测试，它们的目的就是去衡量使用和抛出异常处理的代价。第一（Listing 2）是比较使用异常处理和通过函数返回值来传递信息给调用者这两者的代价。第二（Listing 3）是评估在try-catch模块中执行的代价（尽管没有异常处理被抛出）。最后（Listing 4）就是评估遍历执行try-catch模块的代价（同样，这没有异常处理被抛出）。

Mstress。 这一个例子的目的是，在假设分配比回收优越的基础上，看看垃圾回收语言是否在高的内存利用率上有重要的非线形关系。这里存在四种测试，每一个都牵涉到分配与释放（ C 和 C++）或者丢弃（C#, D, 和 Java）在一个时间段内的内存块。这些块大小是通过相同的伪随机数算法生成的（详见文章的第一部分），这能使块的大小处于1至1000之间，从而在确保每种语言在相同的环境下测试时仿效现实世界中的分配。第一种测试（Listing 5）通过一个不断循环的变量分配了1000个内存块，目的是看看频繁地分配会不会“留下”更多的碎片，这些碎片会阻碍分配的进行直到突然产生明显的GC收集。第二种测试（Listing 5）增加了1000次循环中分配的次数，以测试由不断增加的内存负担引起的性能的 损失 。 第三和第四种测试（没列出来）跟前两个相似，它们增加了另外的内存块和分配/回收的交叉活动，目的是为了模拟不断增加的内存碎片。 C使用malloc()/free()，而C++，C#，D和JAVA用new[]。

rafile 。这一个例子（ Listing 6）评估各种语言从大文件中随机读取的能力。它利用某种伪随机算法（详见文章第一部分）来模拟在大文件中的查找/读取。这里用到了两个文件，一个4.2MB，一个21.1MB。在每一个查找点，四个字节被读取，并且和一个运行值进行异或运算（这样有利于证明所有的语言以相同的方式查找和读取）。有意思的是，原始的运行程序读了32位的整数，但不幸的是，JAVA用了network byte-order而不是host byte-order，这与C, C++, 和D的machine-order reading是不相容的。

Raii（类） ： 这最后的例子目的是为了评估没有内建支持这个非常重要的语言特征（很不幸 C#和Java都没有）而付出的代价。此例子表达了通过资源句柄XUser 类型从XFactory资源管理器分配X资源到客户端代码(见代码段7)。在C++和D语言中，XUser 提供一个析构函数，在析构函数里分配的资源自动地回收到资源库，资源在这种情况下是个信号量，.NET和D的执行代码可从 http://synsoft.org/dotnet.html 和 http://synsoft.org/d.html 下载。C#、D和Java 提供它们自己抽象的同步机制，但我需要一个信号量去引起交叉线程的竞争，去保证同样的同步机制以便所有语言的进行生动的比较。此信号量在每种语言执行代码中都有最初可获得的五个键值。

尽管 C#的XUser 类有一个析构函数，但此析构函数仅在实例进行垃圾碎片收集时被调用。（C#使用析构函数的语法，但编译器把它翻译成 CLR （公共语言运行时刻）的 Finalize() 方法。）这种情况跟 Java一样。C# 还尽量更多地支持习惯用语（虽然它支持的还不够），这是通过使用引用声明来实现的，正如表7所示。（为了方便，“using-ed”类型必须实现 IDisposable 接口，否则声明无效），一个明显的问题是类的使用者必须承担确保语义的正确的负担，而不是类的开发者。这是奇怪的二分法：C#是面向对象的，但它依靠类的使用者对类的内部执行代码的足够理解以决定是否需要此类的直接析构。C++和D语言过程明确，由类自己决定：C++通过析构函数的执行，D提供析构或终止函数，类声明验证关键字 AUTO （没有这些，它按C#和Java的方式运行正常的垃圾碎片收集程序）。

C#语言使用 USING 声明（和 IDisposable 接口）的一个可替代方法是依靠垃圾回收。在形成这个情况之前，我假设当内存使用率达到触发阀值或者主线程空闲/等待的时候启动垃圾碎片回收。（我不知道这种误解是怎么形成的，或许只是异想天开）。当我在执行 Raii2 例子的最初版本的时候（变量没有使用 USING 声明），处理进程马上挂起。很明显，在其他线程堵塞时垃圾碎片收集没有触动，只有在内存消耗到一定程度才触动。因此，为了程序执行，我们被迫在另一个工作线程中自己剔除垃圾碎片收集。当然，这在实际编程中是非常可笑的执行策略，执行结果证明了这一点。

结论

大部分的结果是以绝对运行时间数（全部循环或每循环）或者 C#的执行时间和C，C++，D，Java分别的百分比来表达的。在后一种方式，围绕着百分刻度的结果表示C#的性能比率，高的值表示C#的性能优越，低的值表示相对低下。 Raii 的情况是个例外，在这里结果是以C++（Digital Mars）时间的百分比表示的，由于垃圾碎片收集代码的消耗，调用时间值是以对数刻度表示的。这说明在对数比例上归根于非常高的垃圾处理花费.

BOX . 从图 1中我们能看出,在合理范围里(C#语言的97%-271%)对于所有编译语言解除封装操作(就简单整形数据)成本的差别：最差的是C++(Digital Mars)，成本是C#的271%,最好的是C++(Intel) 成本是C#的97%.假设执行相对比较简单的 异或 运算, C#几乎可以像 Intel那样出色，你对这个并不会感到很惊奇，但你相信C＃要比C++(Digital Mars)和D模板实例快两倍.我有些惊讶C++(Digital Mars)这个相对弱的性能,特别是和D比起来它要慢得多，然而他们出自同一开发商。

显然这个封装花费是有意义的 ,相当于C++模板花费4-10倍.这个测试仅仅包括整数,相对来说可能不能完全反映特殊类型.虽然如此,我们能有把握断言这个模板轻易赢得了性能战.有趣的是就他们各自的成熟度而言，C#要比java稍好,

差距并不大 (小于4%).(我想可能由于.NET处理目标JIT3。【3】)。更有趣的是,事实上在未封装的形态下,c#明显比java快.

除了图 1以外,有人认为,不抛出的异常variants都是是比抛出的异常副本要快的(如图2). 用 c和c++,Intel完成任务要比所有其它不抛出的异常variants快.c#紧随其后。似乎c,c++,D(不考虑编译器)在异常处理上花费大致相等,符合win32异常处理机制的预期限制因素.我们能看到三种语言在抛出异常variants上的差别是比较小的,很可能的原因是由于有相关的额外的管理消耗关系 (c++规定执行破坏功能的堆栈是从捕获点到抛出点的来回).

我发现有趣的是在抛出异常variants方面c#和java的执行是有关系的.

因为这两种语言语义在异常抛出处理要胜于返回当前错误值 ,也胜于其它语言,

尤其 c语言所呈现的关系执行调用.我非常赞同Brian Kernighan和Rob Pike

(<>,Addison Wesley,1999)所说的例外仅仅在例外条件的使用,并不是必然会发生的.然而人们能容易看到为何服务器在处理巨大数量的数据的时候可能出现的例外,而经常担心性能的问题.正是如此,java以小于其它语言25%的消耗给人深刻的印象.由此我们限定win32,采用两个有代表性的差不多的c编译器来构造例外处理,虽然没有定论,但是我认为java使用了不同的机制.

那么c#的异常抛出性能如何呢?在相关条件下,相对其他语言而言，使用异常处理语句是不使用异常处理语句的21-77倍，而c#则是191倍;鉴于Java的出色表现，.net工具应该引起注意了。

Except-2. 这个图表是为了弄清楚在一个 try-catch范围内异常处理语句的执行是否耗时,如图3,大多数语言的表现同预期的一样:c、c++和D对于Digital Mars是类似的;Intel c 和c++比其它都好.c#要比java快.相比较就性能而言,

c#是很优势的,令人感兴趣的是，c#在进行异常处理是耗时比不进行时还要少.产生这种结果肯定是有原因的(这个结果是经过了多次验证的), 但由于对于c#异常处理机制我没有很深的认识，我不能做出合理的解释.同样,虽然并没有定论,对于D来说，是否进行异常处理对结果似乎并无影响！.
我认为这是因为它不用清除栈内数据， java也有大致相同的自由度，并且表现出的差异也并不大。

except-3 如图表 4所示,测试结果与预期大体相符。除了D编译器的结果中微不足道的差异，所有的语言在遍历异常处理语句的时候都比不进行是耗时要长，尽管如此，我仍然对在这两种情况下差异如此之小感到吃惊。我们通常认为使用异常处理机制会耗费时间，并且我认为遍历异常处理语句会在启动和完成上耗费大量时间；事实上，我一开始就预期两者的差异将会非常地显著。然而，在这个测试当中，两者的差异相当不明显。

但是这个结果并不难理解，导致差异如此小的原因首先在于：这次测试太过于纯粹。这次测试的所有异常处理（类型）都是 int型的。尽管并没有异常被抛出，这样做的目的在于避免在异常处理体的构造（和析构）上耗费时间和消除各编译器处理机制不同所造成的影响。其次，本次测试中没有基于框架的结构体，因为在C++中，尽管析构函数并不会真正被调用，析构函数调用方面的准备也是必须进行的，这样也会造成时间的耗费。（注意析构函数无论异常是否被抛出都会被调用。）这些耗费都会造成测试的不公平，所以我们选择了int型。注意到程序不论是因为异常抛出而中止还是正常退出，析构函数都是要被调用的。所以它仅仅做为勾子而被添加进这些额外的函数调用中。然而，我认为所有的这些因素并不是很充足，它们仅仅使我们可以从那张表里知道当不使用的时候异常的开销是非常小的。很自然，这也正确的表明了一个人对所有语言性能(perform)的期望，当然我们要给它足够的信任.

metress-1 这个测试很清楚的表明了在不使用内存分配机制的展示 (exhibit)中不断增长的对固定数量的内存快（随机大小）分配/释放的循环的反应是非线性的。事实上，在很大程度上它们从没有线性(增长)的趋势:从性能上来说并没有什么变化(见图5),除了在一些低循环(low interations)上有所不同之外.(有趣的是，那些低循环的非线性是有意义的--占到了全部命令的50%还多--当然这仅仅是对c#和java而言).不管内存分配机制是否在每次特循环结束后都立即恢复对1000个内存块的释放,或者仅是简单的把它们交给GC在以后的某个时间处理,语言/运行库总是看上去几乎完全不受这些循环执行的影响.

在这组性能相对的测试中，我们可以清楚的看到一些它们之间的不同。在使用 Digital Mars 分配方式的语言中，C和C++的表现是最好的。Visual C++的运行库比使用Digital Mars的语言低大概2.5-3倍，对于使用Digital Mars 的语言和Visaul C++运行库来说，C和C++基本上是相同的。最后,很明显，Java 比C#慢了3-4倍，而比C慢了差不多7倍.

mestress -2

就像我们从图表中看到的，在一定数目的分配释放内存的循环中内存块（随机大小）的不断增长的反应是变量的引用是非线性表现的。这正是我们所希望的，因为在每次循环中分配的内存总量是按指数方式增长.每次循环所分配的内存的大小都低于10，000块.使用Digital Mars分配方式的C 和C++的效率依然是极为优秀的。只是效率表现上低于平均值，而这里也不得不提到java，它的表现同样不好.Visual C++的运行库（C和C++都适用）相对于C#，D 和Java来说，有一个不错的开始，但它很快就降到了一个很低的水平上。

Java在每次循环是使用10，000内存块之前的表现非常有竞争力，并在这一点急剧上升。D在整个测试中都几乎有着一致表现.几乎一直都是非线性的，这与C#很接近。

如果可能的话，我都希望看到一条总够长的X轴，C#在内存溢出的情况下仍然保持每次循环不超出10，000内存块的水平并预防这种情况的出现。（D和Java似乎也做的到，但那也只是类似C#的行为一旦被发现就中止测试。)

mstress-3 和 4 从前两个测试(variants)看,除了时间的的增长，反复的交叉存取和块变量在执行上的表现并没有什么不同。曲线的走势或者说不同的语言/运行库的相对表现在这一点上没有什么明显的改变。

我认为C和C++，在使用外部free/delete的条件下，重新使用的新近释放的碎片。相反的，我很难想像出C#,D和Java 是如何使用垃圾收集机制周期性寻找每次循环所分配的内存从而尽可能的减少由内存碎片所引起的负面效应的,或者在这个跟本就没有产生碎片.除去这些不同，这两种方式的表现还是很相似的。

这只是一种理想的我们所希望的分配机制的表现 ---毕竟，那是一个很极端情况，所有内存分配都可以在给定的周期内完全返回---虽然程序的执行都达到的目的。

rafile. 这次测试中我所希望是那些语言实际 (效率)上并没有什么不同.除了C++的执行也许比其它的低上几个百分点.

图表 7中可以看出，C#的在文件的随机存取上比C(使用Digital Mars)要好,但低于C++(使用Intel和VC6的连接库),和D与Java现表现基本持平。但是C++运行库表现出令印象深刻的性能。

从所有这一系列测试来看，Intel 似乎已经能够产生性能不错的代码了。但是它的连接的运行库头文件却是Visual C++ 6.0的，这个（大概）不是由Intel编译器产生的。因比它几乎是以压倒性的性能优势超过了DMC，这主要是由于各自的Digital Mars 和微软Visual C++运行库的性能。(我承认有点吃惊，对于些测试结果正好可以反对两个卖家的名声--应该或是不应该得到的)。这也表明一个人的偏见是非常没有理由的。

另一件值的注意的事就是对不同大小文件访问的开销都非常的小。这也表明所有的语言都利用操作系统的优势很轻易的达到了相同的程度。

raII . 从图 8中我们能看出使用statement的C#的表现只有C++析构函数效果的一半。D的性能与之相当，虽然产生的代码中有错误（或者是D的Phobos运行库),当进程创建的对像超过32，000左右的时候会使该进程挂起，从而防止过多（一个以上的）通讯中的数据点被确定的使用.在这组单独的测试中我们可以看到RAII对C#和D的支持是很完善的，但并不如想象中那样优秀。如有你要做很多scoping--并且你想，也许要足够的robustaness的帮助---你最好还是选择（stay with）C++。当依赖于.NET的垃圾回收机制时，因为处理过程只是简单地被挂起，所以C＃的性能比较难以测算。可是我们不希望.NET经常调用它的垃圾回收线程，但我找不到理由解释为什么回收线程不以较低优先级在内核中等待，当有垃圾对象需要被回收和主线程空闲时再进行有效的回收。当然，我在垃圾回收方面不是专家，并且可能有一种合理的理论原因说明这为什么不是一个好的处理方法。

GC（垃圾回收）即使响应的更灵敏，我们可以在它的性能结果上看出效果并不与之匹配。对应第二组数据指针的方法表明了GC每隔1ms被触发一次。

GC（垃圾回收）的方法比使用使用声明慢了近千倍，所以这不仅仅是一个技术问题的范围。自然，这跟关于这个例子的假设有关，同时跟几乎每个人都用垃圾回收机制去管理频繁争用的资源的释放这个不辩的事实有关，但我没预计到这个变量的性能是如此之差。同时这也给了读过Java/.NET书籍的C++程序员对于书籍建议（或许说依靠）使用终止函数来清除资源而感觉疑惑的一个解释。

结论

在第一篇文章，我对于不同的环节得出不同的结论，这些环节或是语言本身造成的，或是库或者二者造成的，在这里我也这么区分，因为语言特征而产生的影响的部分通常涉及：异常，封装 /模板和RAII的实现。文件存取部分可以看作直接对库函数的操作。（没有任何一种语言阻止写替换操作，虽然这样做并不是很容易）。内存管理部分受语言和内存的影响――虽然我不清楚可以用哪一种管理机制去替代C#和JAVA的缺省的内存管理机制，但是对于其他语言这是很简单的。

封装。当我们比较封装和模板时，我们可以看出模板明显比封装出色很多。我相信这不会让大家感到很惊奇，但是事实上封装消耗的系统资源是模板的十倍。自然，作为模板类库的作者（ http://stlsoft.org/ ），我得出这个结论也许带有偏见，但是这些数据在表示更广泛的情况时，他们自身就说明这一点。在后面，我将说到容器和算法，我们将看到比预计更多的这样的结果。

至于有关异常情况，我想讲四点：

1.在所有的程序语言中，使用异常处理从调用的函数过程中返回，而不是保留他们作为异常事件的指示，将导致执行花费巨大的成本。

2.C#的异常处理机制相对于其他被测试的语言效率是极低的.

3.在有异常处理的上下文环境下运行（比如用try-catch的情况）对于性能没有多大影响，除了C#，它为了提高性能（实际上，我对于这种结果很不理解，并且怀疑这是.NET运行期的一个人为结果而不是C＃/.NET的一般特征。）

4.交叉于异常上下文的执行（比如说进入try-catch和/或 离开try-catch）对于系统性能的影响基本上是非常小的。

Raii. C#支持的RAII例子比C++在性能方面差，虽然不是很多，但与D相比差别无几，基本一致。（这种一致指出了在处理堆分配对象的确定性析构时的基本限制）然而，从理论观点，或从易用性和/或稳健性的实践观点来看，这里还是有很大差距的。C语言缺乏机制可以解释为年代已久，并且它是一种程序语言。很遗憾，java缺乏这种机制，但是它只是可以解释为忽视了。（至今为止我们已经用java8年左右了，所以“忽视”可能也有些牵强。）C#在这方面的努力还不成熟（因为它更多地依赖类的用户而不是类的作者），很奇怪的是C#/.NET很多优点都是在Java中被看作瑕疵/遗漏的地方，比如属性，输出参数，和无符型。

Mstress. 这个内存测试的目的是证明如果频繁的内存分配加上垃圾回收机制是否会导致—— C#, D, 和Java这些包含垃圾回收的语言严重的非线形，这明显没有。这个结果可以看出所有的语言/库表现的非常合理的。这里我们可得出几个有趣的结论：

1.C语言和C++语言，提供正确的库支持，他们内存分配空间最快。毫无疑问，部分原因由于它们没有初始化字符数组的内容。根据结果，我重新对C语言进行测试，用calloc()替代malloc()，测试结果很接近C#，虽然仍然会高出5个百分点。

2.内存碎片（只要轮流存取第三和第四个变量）不会在很大程度上影响内存分配的性能，不会增加总体负担。

3.如果垃圾回收器安排在没有使用的内存区之后不执行（我假设这是可以的），这将不会对性能有太大的影响。我假设，这说明了C#是第一个会内存枯竭的语言，所以我们可以假定它们通过使用大量的内存空间在内存分配性能方便取得平衡，并且相信在现实的环境中有这种机会运行垃圾回收。

4.通常更希望体面地降低性能―就象C（Digital Mars）的方式――而不是在各个方面都有很强大的性能，然后在某些未知的阀值化为乌有：在服务器环境下，某一时刻提供一个慢点的服务比导致崩溃可能要好。由于对Digital Mars和Visual C＋＋，C和C＋＋的运行实际上是相同的，我们可以假定因为与通过new操作符的调用的交流而增加的成本可以忽略，并且在C和C++之间没有本质的区别。

5.C#内存分配时间会比Java快上3～4倍。

总的来说，这个结果并不象我想象的那样：我期望C和C++在中小应用比 C#，D，和Java稍微落后，但在大型应用中远远优于。真是学无止境。

Rafile . 对于文件的随机存储结果可以看出一些重点。我认为最重要的一点是仔细的选择库。之所以C++的运行效果看上去要比C和其他的语言好很多，就是因为库的原因。当把C＋＋的性能（Intel 和VC6库）和其他语言/编译器进行比较时，用其他任何一种都很给人留下深刻的印象。自然，这边的例子是故意的，但这么大的性能差别的事实——比C#和 Java快23倍，我们可以期待在现实情况中性能的有意义的差别。（这里，再次证明了偏见是错误的：我很厌恶所有的io流，从很多方面很容易能看出它的效率很低，当然也不能说全部这样。我对于这样的性能印象很深刻）。

详细的总结了C#的性能以后，我想就我们在其他语言方面的研究发现做一个简短的介绍。

1.C处理异常事件是不错的，特别是在存储和文件（提供正确的库连接）有非常好的表现；它能提供所有我们能预期的效果，但是与后来的高级语言相比，吸引不了更多的学习者。

2.C++处理异常事件也不错，特别是在存储和文件（提供正确的库连接）有非常好的表现，而且包含模块的概念和有效的RAII；它始终得到我的钟爱，我认为它在未来的很长一段时间内都是编程的最佳选择。

3.D在异常事件处理上不是很太好，在文件处理上处于一般水平，在存储方面有比较合理的相关性能和非常不错的线性度，有模块和RAII（虽然语言本身有很多的bug产生，使得很多的处理过程被挂起）；当这语言经过它的初级阶段，期望会得到不错的效果。

4.Java在封装和内存管理的性能上表现最差，不过它有好的异常事件处理，但没有一点模块和RAII的概念；它不指望会达到真正的美好，我认为C#/.NET可以衡量出它的高低，至少运行在Windows平台上 。

摘要

从第一部分开始，就给出全文的延伸的意思，从性能方面，如何能更好的用C#/.NET写出很好的软件。在第一部分里，一些结果虽然不是很值得注意，但是有很多的地方还是令人叫奇的（至少我是这样的！）。

这些研究结果展示了C#可以提供非常好的性能效果——至少在我们测试的范围内是这样——同时不能把它如同象过去把Visual Basic和一些扩展版本的Java当作一种性能差的语言来对待。对我而言，我比较注意语言运行的性能，当然，他们的表现也会超出我的预期效果。我所提出的严肃评论是从语言特征的观点和对多个编程范例的支持方面得出的。

作为一个最初使用C++的程序员，我从特定的观点得出这些比较结果。这可以从RAII和封装测试以及它们的语言解释上看的出来。在某种意义上来说，这就好比比较苹果和橙子，对于不同背景的人们可能会对我为什么如此强调模板和确定性析构感到疑惑，没有这些他们也进行的很好。

毫无疑问，模板给C++带来了非凡的革命，它能支持群组合作，或者独立运行，范例是无可比拟的。Java由于缺少模板和强制要求任何东西都是对象，而被批评了很长时间。.NET框架在这方面做法一样也很让人失望；可能由于Java缺少模板而他们可以在.NET环境下得到（他们确实达到）让更广的开发团体感到信赖并接受了它。

缺少对RAII的支持对GUIs（通用用户接口）是非常好的，这是在严格的框架内操作的软件——即使象J2EE这样精密复杂和高吞吐量的语言，和非关键的程序。但复杂的软件不必要因为它而复杂。在最好的情况下，到处都是最终模块，只要在Finalize()里函数里添加Close()方法就可以了。在最坏的情况下，滞缓或者随机的资源泄漏都会导致系统的崩溃。更甚于以上的，如果OO（面向对象）——就象C#和Java所有都是对象——是你的目的那更让我不安，第一个要失去的就是对象自己清除自己的责任，我没办法理解这个。（我知道一个非常出名的C++程序员——当然我不能告诉是谁，他告诉我当他在课程中突出RAII和模板的重点时，那些非使用C++的人们露出的滑稽表情，让他感觉好象他丢失了什么东西）

D是使用垃圾回收的语言，默认是非确定性析构,有很多地方与C#和Java相似，但是尽管如此，它还是兼容支持RAII的习惯同时具有模板。并且它是一个人写的！我不明白为什么我们对Java或者C#（.NET其它语言也是一样）印象如此深刻，即使有它们支持RAII和模板的缺点，而我们又能比较这些。有可能C#/.NET成功的原因和Java一样，有大量的，有用的库文件（C和C++应该从中学习，D应该去发展），和有一个强有力的后台。

最后，我想说对于所有的性能结果的比较分析，你必须明智地使用这些结果。我努力使自己公平，选择我相信是公平和有意义的测试。但你一定要判断的出这些例子仅代表了广大可能性的的一小部分（不是无限意义上的），它们不是实际的程序，仅仅是测试而已并且把它简化了，其中不可避免的带有我个人的某种偏见在里面。通过逐步的方法，我希望降低这些因素。但你在阅读和使用这些结果的时候要保持留意。

感谢

我要感谢 Walter Bright提供给我最新的Dv0.62版本，能够完全的测试异常事件。感谢Intel的David Hackson给我提供了C/C++编译器。还要感谢Scott Patterson帮我选择了切合实际的测试方法（他总是不断的在我烦躁、偏题、愚蠢的时候提醒我）。还要感谢Eugene Gershnik 对于我的一些断言给了我严厉的反驳，帮助我适当地注意一些防止误解的说明。

Notes and References

[1] The C++ Programming Language, Bjarne Stroustrup, Addison Wesley, 1997

[2] The Software Optimization Cookbook, Richard Gerber, Intel Press, 2002

[3] Applied Microsoft .NET Framework Programming 1 st Edition, Jeffrey Richter, Microsoft Press, 2002

[4] Described in “ Win32 Performance Measurement Options, ” Matthew Wilson, Windows Developer Network, Volume 2 Number 5, May 2003.

·类机制（封装与模板）

·异常

·内存— 重点

·大型文件的随机访问

·资源获取初始化

正如我在第一部分提到的，这里所做的测试只是针对程序性能的一小部分，硬件及操作系统的配置是测试语言 /编译器/库函数的机器的典型配置：2-GHZ，512-MB，Pentium IV，Windows XP Professional。 这里我们看到的任何结果揭示了在其它环境下可能的性能，这不说明可以假设这些结果就是正确的典型例子。 最后要说明的是，当我提到“C#比Java好”等结论的时候，一定是指“在特定的测试环境的条件下”，这一点请你铭记在心。

性能评价

所有的代码还是用和第一部分一样的编译器编译。 C#代码在.NET框架 1.0.3705（可从http://microsoft.com/netframework/免费下载）下，由Visual C#.NET 编译器v7.00.9466编译。D代码由Digital Mars D 编译器 Alpha v0.62 (可从http://www.digitalmars.com/免费下载) 编译。Java代码由J2DKSE1.4.1-02 ( 可免费下载 http://java.sun.com/ ) 编译。 C和C++代码 ( 单线程 , 包括 raii , 和静态链接库 ) 由使用 STLPort v4.5的Digital Mars C/C++ v8.33 ( 可从 http://www.digitalmars.com/免费下载 ) 和使用 Visual C++ 6.0的头文件和库文件的Intel C/C++ v7.0来编译。所有这些编译器均使用最优化处理 ( set for speed ) ; Intel 用-QaxW flag [2]提供两套编码路径：一个是针对有SSE2的Pentium IV处理器，另一个是针对其他所有的处理器——在运行时选择合适的一个。（因为Intel编译器只适用于Intel处理器构造，特别是在这个测试中的Pentium IV，这编译器的编译结果必须在此基础上评价，不能在其他的处理器上进行同样的过程，比如Athlon，甚至是旧版本的Intel处理器也不行。）

后面将要描述我们测试的假想的五种例子中的性能表现。他们都用2-GHZ，512-MB，Pentium IV，Windows XP Professional的配置，并沿用在第一部分用的性能分析系统。每一种语言所编程序的调试都执行7次，同时没有其他占线过程，去掉最高速的和最低速的，纪录平均值。所有的时间信息，通过仅区分相应时间区间的高性能计时器保存下来。（C用户调用Win32 API QueryPerformanceCounter() ；C++ 用 Win-STL ' s performance_counter [4], 可在http://winstl.org/找到 ； C# 用 SynSoft.Performance.PerformanceCounter ，可在 http://synsoft.org/dotnet.html找到； D 用 synsoft.win32.perf.PerformanceCounter , 可在http://synsoft.org/d.html找到；Java 用 System.currentTimeMillis() .）每一个测试程序都包含一个启动迭代的程序，这样可以将启动或缓冲时的影响最小化。

在每一个例子中的C#，C++和D的特征: C在所有 保存 封装和 raii( 类)的地方出现，因为它没有这两种例子必需的语言特征。 raii 没有出现Java，因为Java甚至连 Resource AcquisitionIs Initialization (RAII [1])的机制也没有，所以它仅仅作为在GC-kicking的一个练习。简单的说，我不会展示所有的语言的每一个例子的所有特性，但是所有这些都包含于在线记录中（连同产生他们的Digital Mars make-compatible make-file）。

下面就对测试性能的例子进行评价 :

封装 。这个例子（ Listing1）的目的是比较不同语言（除了C）在类机制上的代价，这些语言并不完全支持相对于它们所做的所有类型的一般处理。尤其是C#和Java一般不能存储和使用它们的内置类型实例，比如int，long，bool等等，同样，对于从这些实例派生的类型也不行。相反C++和D都支持模板，它可以给任何类型的一般性操作带来方便。在以后的文章里，我将详细地讲解容器。但在这个章节将不会用到它，如果提及它反而会分散对于封装意义的理解。C#和Java中未封装的变量传递ints给异或函数，封装变量传递整形值在Int32（C#）和Interger（Java）的实例中。注意Java不支持模糊的封装（这被证明是好的因为编译器将对于这种封装带来的低效给予警告），所以实例必须明确地被创建（在列表1中标记“Java ” 处可以看到）。 C++和D的运行是简单的使用模板，这就是它们的泛型机制。（在这里我不对“一切都是对象”的模板的好处作深入探讨，但是我将在这期的姊妹篇Stepanov camp中对它做详细讲解）。

异常处理 。异常的语义在各种语言之间有很大的区别。 在 C++，异常处理和调用析构函数一起沿着堆栈操作下来，然而在有垃圾回收的语言中，这些对象被丢弃，直到将来的某一时刻被收集。 这样，就无法对各种语言进行有意义的比较。所以在这个例子中，只能通过将一段 using/aware代码与另一段没有异常处理支持的相同代码进行比较。这个例子有三种测试，它们的目的就是去衡量使用和抛出异常处理的代价。第一（Listing 2）是比较使用异常处理和通过函数返回值来传递信息给调用者这两者的代价。第二（Listing 3）是评估在try-catch模块中执行的代价（尽管没有异常处理被抛出）。最后（Listing 4）就是评估遍历执行try-catch模块的代价（同样，这没有异常处理被抛出）。

Mstress。 这一个例子的目的是，在假设分配比回收优越的基础上，看看垃圾回收语言是否在高的内存利用率上有重要的非线形关系。这里存在四种测试，每一个都牵涉到分配与释放（ C 和 C++）或者丢弃（C#, D, 和 Java）在一个时间段内的内存块。这些块大小是通过相同的伪随机数算法生成的（详见文章的第一部分），这能使块的大小处于1至1000之间，从而在确保每种语言在相同的环境下测试时仿效现实世界中的分配。第一种测试（Listing 5）通过一个不断循环的变量分配了1000个内存块，目的是看看频繁地分配会不会“留下”更多的碎片，这些碎片会阻碍分配的进行直到突然产生明显的GC收集。第二种测试（Listing 5）增加了1000次循环中分配的次数，以测试由不断增加的内存负担引起的性能的 损失 。 第三和第四种测试（没列出来）跟前两个相似，它们增加了另外的内存块和分配/回收的交叉活动，目的是为了模拟不断增加的内存碎片。 C使用malloc()/free()，而C++，C#，D和JAVA用new[]。

rafile 。这一个例子（ Listing 6）评估各种语言从大文件中随机读取的能力。它利用某种伪随机算法（详见文章第一部分）来模拟在大文件中的查找/读取。这里用到了两个文件，一个4.2MB，一个21.1MB。在每一个查找点，四个字节被读取，并且和一个运行值进行异或运算（这样有利于证明所有的语言以相同的方式查找和读取）。有意思的是，原始的运行程序读了32位的整数，但不幸的是，JAVA用了network byte-order而不是host byte-order，这与C, C++, 和D的machine-order reading是不相容的。

Raii（类） ： 这最后的例子目的是为了评估没有内建支持这个非常重要的语言特征（很不幸 C#和Java都没有）而付出的代价。此例子表达了通过资源句柄XUser 类型从XFactory资源管理器分配X资源到客户端代码(见代码段7)。在C++和D语言中，XUser 提供一个析构函数，在析构函数里分配的资源自动地回收到资源库，资源在这种情况下是个信号量，.NET和D的执行代码可从 http://synsoft.org/dotnet.html 和 http://synsoft.org/d.html 下载。C#、D和Java 提供它们自己抽象的同步机制，但我需要一个信号量去引起交叉线程的竞争，去保证同样的同步机制以便所有语言的进行生动的比较。此信号量在每种语言执行代码中都有最初可获得的五个键值。

尽管 C#的XUser 类有一个析构函数，但此析构函数仅在实例进行垃圾碎片收集时被调用。（C#使用析构函数的语法，但编译器把它翻译成 CLR （公共语言运行时刻）的 Finalize() 方法。）这种情况跟 Java一样。C# 还尽量更多地支持习惯用语（虽然它支持的还不够），这是通过使用引用声明来实现的，正如表7所示。（为了方便，“using-ed”类型必须实现 IDisposable 接口，否则声明无效），一个明显的问题是类的使用者必须承担确保语义的正确的负担，而不是类的开发者。这是奇怪的二分法：C#是面向对象的，但它依靠类的使用者对类的内部执行代码的足够理解以决定是否需要此类的直接析构。C++和D语言过程明确，由类自己决定：C++通过析构函数的执行，D提供析构或终止函数，类声明验证关键字 AUTO （没有这些，它按C#和Java的方式运行正常的垃圾碎片收集程序）。

C#语言使用 USING 声明（和 IDisposable 接口）的一个可替代方法是依靠垃圾回收。在形成这个情况之前，我假设当内存使用率达到触发阀值或者主线程空闲/等待的时候启动垃圾碎片回收。（我不知道这种误解是怎么形成的，或许只是异想天开）。当我在执行 Raii2 例子的最初版本的时候（变量没有使用 USING 声明），处理进程马上挂起。很明显，在其他线程堵塞时垃圾碎片收集没有触动，只有在内存消耗到一定程度才触动。因此，为了程序执行，我们被迫在另一个工作线程中自己剔除垃圾碎片收集。当然，这在实际编程中是非常可笑的执行策略，执行结果证明了这一点。

结论

大部分的结果是以绝对运行时间数（全部循环或每循环）或者 C#的执行时间和C，C++，D，Java分别的百分比来表达的。在后一种方式，围绕着百分刻度的结果表示C#的性能比率，高的值表示C#的性能优越，低的值表示相对低下。 Raii 的情况是个例外，在这里结果是以C++（Digital Mars）时间的百分比表示的，由于垃圾碎片收集代码的消耗，调用时间值是以对数刻度表示的。这说明在对数比例上归根于非常高的垃圾处理花费.

BOX . 从图 1中我们能看出,在合理范围里(C#语言的97%-271%)对于所有编译语言解除封装操作(就简单整形数据)成本的差别：最差的是C++(Digital Mars)，成本是C#的271%,最好的是C++(Intel) 成本是C#的97%.假设执行相对比较简单的 异或 运算, C#几乎可以像 Intel那样出色，你对这个并不会感到很惊奇，但你相信C＃要比C++(Digital Mars)和D模板实例快两倍.我有些惊讶C++(Digital Mars)这个相对弱的性能,特别是和D比起来它要慢得多，然而他们出自同一开发商。

显然这个封装花费是有意义的 ,相当于C++模板花费4-10倍.这个测试仅仅包括整数,相对来说可能不能完全反映特殊类型.虽然如此,我们能有把握断言这个模板轻易赢得了性能战.有趣的是就他们各自的成熟度而言，C#要比java稍好,

差距并不大 (小于4%).(我想可能由于.NET处理目标JIT3。【3】)。更有趣的是,事实上在未封装的形态下,c#明显比java快.

除了图 1以外,有人认为,不抛出的异常variants都是是比抛出的异常副本要快的(如图2). 用 c和c++,Intel完成任务要比所有其它不抛出的异常variants快.c#紧随其后。似乎c,c++,D(不考虑编译器)在异常处理上花费大致相等,符合win32异常处理机制的预期限制因素.我们能看到三种语言在抛出异常variants上的差别是比较小的,很可能的原因是由于有相关的额外的管理消耗关系 (c++规定执行破坏功能的堆栈是从捕获点到抛出点的来回).

我发现有趣的是在抛出异常variants方面c#和java的执行是有关系的.

因为这两种语言语义在异常抛出处理要胜于返回当前错误值 ,也胜于其它语言,

尤其 c语言所呈现的关系执行调用.我非常赞同Brian Kernighan和Rob Pike

(<>,Addison Wesley,1999)所说的例外仅仅在例外条件的使用,并不是必然会发生的.然而人们能容易看到为何服务器在处理巨大数量的数据的时候可能出现的例外,而经常担心性能的问题.正是如此,java以小于其它语言25%的消耗给人深刻的印象.由此我们限定win32,采用两个有代表性的差不多的c编译器来构造例外处理,虽然没有定论,但是我认为java使用了不同的机制.

那么c#的异常抛出性能如何呢?在相关条件下,相对其他语言而言，使用异常处理语句是不使用异常处理语句的21-77倍，而c#则是191倍;鉴于Java的出色表现，.net工具应该引起注意了。

Except-2. 这个图表是为了弄清楚在一个 try-catch范围内异常处理语句的执行是否耗时,如图3,大多数语言的表现同预期的一样:c、c++和D对于Digital Mars是类似的;Intel c 和c++比其它都好.c#要比java快.相比较就性能而言,

c#是很优势的,令人感兴趣的是，c#在进行异常处理是耗时比不进行时还要少.产生这种结果肯定是有原因的(这个结果是经过了多次验证的), 但由于对于c#异常处理机制我没有很深的认识，我不能做出合理的解释.同样,虽然并没有定论,对于D来说，是否进行异常处理对结果似乎并无影响！.
我认为这是因为它不用清除栈内数据， java也有大致相同的自由度，并且表现出的差异也并不大。

except-3 如图表 4所示,测试结果与预期大体相符。除了D编译器的结果中微不足道的差异，所有的语言在遍历异常处理语句的时候都比不进行是耗时要长，尽管如此，我仍然对在这两种情况下差异如此之小感到吃惊。我们通常认为使用异常处理机制会耗费时间，并且我认为遍历异常处理语句会在启动和完成上耗费大量时间；事实上，我一开始就预期两者的差异将会非常地显著。然而，在这个测试当中，两者的差异相当不明显。

但是这个结果并不难理解，导致差异如此小的原因首先在于：这次测试太过于纯粹。这次测试的所有异常处理（类型）都是 int型的。尽管并没有异常被抛出，这样做的目的在于避免在异常处理体的构造（和析构）上耗费时间和消除各编译器处理机制不同所造成的影响。其次，本次测试中没有基于框架的结构体，因为在C++中，尽管析构函数并不会真正被调用，析构函数调用方面的准备也是必须进行的，这样也会造成时间的耗费。（注意析构函数无论异常是否被抛出都会被调用。）这些耗费都会造成测试的不公平，所以我们选择了int型。注意到程序不论是因为异常抛出而中止还是正常退出，析构函数都是要被调用的。所以它仅仅做为勾子而被添加进这些额外的函数调用中。然而，我认为所有的这些因素并不是很充足，它们仅仅使我们可以从那张表里知道当不使用的时候异常的开销是非常小的。很自然，这也正确的表明了一个人对所有语言性能(perform)的期望，当然我们要给它足够的信任.

metress-1 这个测试很清楚的表明了在不使用内存分配机制的展示 (exhibit)中不断增长的对固定数量的内存快（随机大小）分配/释放的循环的反应是非线性的。事实上，在很大程度上它们从没有线性(增长)的趋势:从性能上来说并没有什么变化(见图5),除了在一些低循环(low interations)上有所不同之外.(有趣的是，那些低循环的非线性是有意义的--占到了全部命令的50%还多--当然这仅仅是对c#和java而言).不管内存分配机制是否在每次特循环结束后都立即恢复对1000个内存块的释放,或者仅是简单的把它们交给GC在以后的某个时间处理,语言/运行库总是看上去几乎完全不受这些循环执行的影响.

在这组性能相对的测试中，我们可以清楚的看到一些它们之间的不同。在使用 Digital Mars 分配方式的语言中，C和C++的表现是最好的。Visual C++的运行库比使用Digital Mars的语言低大概2.5-3倍，对于使用Digital Mars 的语言和Visaul C++运行库来说，C和C++基本上是相同的。最后,很明显，Java 比C#慢了3-4倍，而比C慢了差不多7倍.

mestress -2

就像我们从图表中看到的，在一定数目的分配释放内存的循环中内存块（随机大小）的不断增长的反应是变量的引用是非线性表现的。这正是我们所希望的，因为在每次循环中分配的内存总量是按指数方式增长.每次循环所分配的内存的大小都低于10，000块.使用Digital Mars分配方式的C 和C++的效率依然是极为优秀的。只是效率表现上低于平均值，而这里也不得不提到java，它的表现同样不好.Visual C++的运行库（C和C++都适用）相对于C#，D 和Java来说，有一个不错的开始，但它很快就降到了一个很低的水平上。

Java在每次循环是使用10，000内存块之前的表现非常有竞争力，并在这一点急剧上升。D在整个测试中都几乎有着一致表现.几乎一直都是非线性的，这与C#很接近。

如果可能的话，我都希望看到一条总够长的X轴，C#在内存溢出的情况下仍然保持每次循环不超出10，000内存块的水平并预防这种情况的出现。（D和Java似乎也做的到，但那也只是类似C#的行为一旦被发现就中止测试。)

mstress-3 和 4 从前两个测试(variants)看,除了时间的的增长，反复的交叉存取和块变量在执行上的表现并没有什么不同。曲线的走势或者说不同的语言/运行库的相对表现在这一点上没有什么明显的改变。

我认为C和C++，在使用外部free/delete的条件下，重新使用的新近释放的碎片。相反的，我很难想像出C#,D和Java 是如何使用垃圾收集机制周期性寻找每次循环所分配的内存从而尽可能的减少由内存碎片所引起的负面效应的,或者在这个跟本就没有产生碎片.除去这些不同，这两种方式的表现还是很相似的。

这只是一种理想的我们所希望的分配机制的表现 ---毕竟，那是一个很极端情况，所有内存分配都可以在给定的周期内完全返回---虽然程序的执行都达到的目的。

rafile. 这次测试中我所希望是那些语言实际 (效率)上并没有什么不同.除了C++的执行也许比其它的低上几个百分点.

图表 7中可以看出，C#的在文件的随机存取上比C(使用Digital Mars)要好,但低于C++(使用Intel和VC6的连接库),和D与Java现表现基本持平。但是C++运行库表现出令印象深刻的性能。

从所有这一系列测试来看，Intel 似乎已经能够产生性能不错的代码了。但是它的连接的运行库头文件却是Visual C++ 6.0的，这个（大概）不是由Intel编译器产生的。因比它几乎是以压倒性的性能优势超过了DMC，这主要是由于各自的Digital Mars 和微软Visual C++运行库的性能。(我承认有点吃惊，对于些测试结果正好可以反对两个卖家的名声--应该或是不应该得到的)。这也表明一个人的偏见是非常没有理由的。

另一件值的注意的事就是对不同大小文件访问的开销都非常的小。这也表明所有的语言都利用操作系统的优势很轻易的达到了相同的程度。

raII . 从图 8中我们能看出使用statement的C#的表现只有C++析构函数效果的一半。D的性能与之相当，虽然产生的代码中有错误（或者是D的Phobos运行库),当进程创建的对像超过32，000左右的时候会使该进程挂起，从而防止过多（一个以上的）通讯中的数据点被确定的使用.在这组单独的测试中我们可以看到RAII对C#和D的支持是很完善的，但并不如想象中那样优秀。如有你要做很多scoping--并且你想，也许要足够的robustaness的帮助---你最好还是选择（stay with）C++。当依赖于.NET的垃圾回收机制时，因为处理过程只是简单地被挂起，所以C＃的性能比较难以测算。可是我们不希望.NET经常调用它的垃圾回收线程，但我找不到理由解释为什么回收线程不以较低优先级在内核中等待，当有垃圾对象需要被回收和主线程空闲时再进行有效的回收。当然，我在垃圾回收方面不是专家，并且可能有一种合理的理论原因说明这为什么不是一个好的处理方法。

GC（垃圾回收）即使响应的更灵敏，我们可以在它的性能结果上看出效果并不与之匹配。对应第二组数据指针的方法表明了GC每隔1ms被触发一次。

GC（垃圾回收）的方法比使用使用声明慢了近千倍，所以这不仅仅是一个技术问题的范围。自然，这跟关于这个例子的假设有关，同时跟几乎每个人都用垃圾回收机制去管理频繁争用的资源的释放这个不辩的事实有关，但我没预计到这个变量的性能是如此之差。同时这也给了读过Java/.NET书籍的C++程序员对于书籍建议（或许说依靠）使用终止函数来清除资源而感觉疑惑的一个解释。

结论

在第一篇文章，我对于不同的环节得出不同的结论，这些环节或是语言本身造成的，或是库或者二者造成的，在这里我也这么区分，因为语言特征而产生的影响的部分通常涉及：异常，封装 /模板和RAII的实现。文件存取部分可以看作直接对库函数的操作。（没有任何一种语言阻止写替换操作，虽然这样做并不是很容易）。内存管理部分受语言和内存的影响――虽然我不清楚可以用哪一种管理机制去替代C#和JAVA的缺省的内存管理机制，但是对于其他语言这是很简单的。

封装。当我们比较封装和模板时，我们可以看出模板明显比封装出色很多。我相信这不会让大家感到很惊奇，但是事实上封装消耗的系统资源是模板的十倍。自然，作为模板类库的作者（ http://stlsoft.org/ ），我得出这个结论也许带有偏见，但是这些数据在表示更广泛的情况时，他们自身就说明这一点。在后面，我将说到容器和算法，我们将看到比预计更多的这样的结果。

至于有关异常情况，我想讲四点：

1.在所有的程序语言中，使用异常处理从调用的函数过程中返回，而不是保留他们作为异常事件的指示，将导致执行花费巨大的成本。

2.C#的异常处理机制相对于其他被测试的语言效率是极低的.

3.在有异常处理的上下文环境下运行（比如用try-catch的情况）对于性能没有多大影响，除了C#，它为了提高性能（实际上，我对于这种结果很不理解，并且怀疑这是.NET运行期的一个人为结果而不是C＃/.NET的一般特征。）

4.交叉于异常上下文的执行（比如说进入try-catch和/或 离开try-catch）对于系统性能的影响基本上是非常小的。

Raii. C#支持的RAII例子比C++在性能方面差，虽然不是很多，但与D相比差别无几，基本一致。（这种一致指出了在处理堆分配对象的确定性析构时的基本限制）然而，从理论观点，或从易用性和/或稳健性的实践观点来看，这里还是有很大差距的。C语言缺乏机制可以解释为年代已久，并且它是一种程序语言。很遗憾，java缺乏这种机制，但是它只是可以解释为忽视了。（至今为止我们已经用java8年左右了，所以“忽视”可能也有些牵强。）C#在这方面的努力还不成熟（因为它更多地依赖类的用户而不是类的作者），很奇怪的是C#/.NET很多优点都是在Java中被看作瑕疵/遗漏的地方，比如属性，输出参数，和无符型。

Mstress. 这个内存测试的目的是证明如果频繁的内存分配加上垃圾回收机制是否会导致—— C#, D, 和Java这些包含垃圾回收的语言严重的非线形，这明显没有。这个结果可以看出所有的语言/库表现的非常合理的。这里我们可得出几个有趣的结论：

1.C语言和C++语言，提供正确的库支持，他们内存分配空间最快。毫无疑问，部分原因由于它们没有初始化字符数组的内容。根据结果，我重新对C语言进行测试，用calloc()替代malloc()，测试结果很接近C#，虽然仍然会高出5个百分点。

2.内存碎片（只要轮流存取第三和第四个变量）不会在很大程度上影响内存分配的性能，不会增加总体负担。

3.如果垃圾回收器安排在没有使用的内存区之后不执行（我假设这是可以的），这将不会对性能有太大的影响。我假设，这说明了C#是第一个会内存枯竭的语言，所以我们可以假定它们通过使用大量的内存空间在内存分配性能方便取得平衡，并且相信在现实的环境中有这种机会运行垃圾回收。

4.通常更希望体面地降低性能―就象C（Digital Mars）的方式――而不是在各个方面都有很强大的性能，然后在某些未知的阀值化为乌有：在服务器环境下，某一时刻提供一个慢点的服务比导致崩溃可能要好。由于对Digital Mars和Visual C＋＋，C和C＋＋的运行实际上是相同的，我们可以假定因为与通过new操作符的调用的交流而增加的成本可以忽略，并且在C和C++之间没有本质的区别。

5.C#内存分配时间会比Java快上3～4倍。

总的来说，这个结果并不象我想象的那样：我期望C和C++在中小应用比 C#，D，和Java稍微落后，但在大型应用中远远优于。真是学无止境。

Rafile . 对于文件的随机存储结果可以看出一些重点。我认为最重要的一点是仔细的选择库。之所以C++的运行效果看上去要比C和其他的语言好很多，就是因为库的原因。当把C＋＋的性能（Intel 和VC6库）和其他语言/编译器进行比较时，用其他任何一种都很给人留下深刻的印象。自然，这边的例子是故意的，但这么大的性能差别的事实——比C#和 Java快23倍，我们可以期待在现实情况中性能的有意义的差别。（这里，再次证明了偏见是错误的：我很厌恶所有的io流，从很多方面很容易能看出它的效率很低，当然也不能说全部这样。我对于这样的性能印象很深刻）。

详细的总结了C#的性能以后，我想就我们在其他语言方面的研究发现做一个简短的介绍。

1.C处理异常事件是不错的，特别是在存储和文件（提供正确的库连接）有非常好的表现；它能提供所有我们能预期的效果，但是与后来的高级语言相比，吸引不了更多的学习者。

2.C++处理异常事件也不错，特别是在存储和文件（提供正确的库连接）有非常好的表现，而且包含模块的概念和有效的RAII；它始终得到我的钟爱，我认为它在未来的很长一段时间内都是编程的最佳选择。

3.D在异常事件处理上不是很太好，在文件处理上处于一般水平，在存储方面有比较合理的相关性能和非常不错的线性度，有模块和RAII（虽然语言本身有很多的bug产生，使得很多的处理过程被挂起）；当这语言经过它的初级阶段，期望会得到不错的效果。

4.Java在封装和内存管理的性能上表现最差，不过它有好的异常事件处理，但没有一点模块和RAII的概念；它不指望会达到真正的美好，我认为C#/.NET可以衡量出它的高低，至少运行在Windows平台上 。

摘要

从第一部分开始，就给出全文的延伸的意思，从性能方面，如何能更好的用C#/.NET写出很好的软件。在第一部分里，一些结果虽然不是很值得注意，但是有很多的地方还是令人叫奇的（至少我是这样的！）。

这些研究结果展示了C#可以提供非常好的性能效果——至少在我们测试的范围内是这样——同时不能把它如同象过去把Visual Basic和一些扩展版本的Java当作一种性能差的语言来对待。对我而言，我比较注意语言运行的性能，当然，他们的表现也会超出我的预期效果。我所提出的严肃评论是从语言特征的观点和对多个编程范例的支持方面得出的。

作为一个最初使用C++的程序员，我从特定的观点得出这些比较结果。这可以从RAII和封装测试以及它们的语言解释上看的出来。在某种意义上来说，这就好比比较苹果和橙子，对于不同背景的人们可能会对我为什么如此强调模板和确定性析构感到疑惑，没有这些他们也进行的很好。

毫无疑问，模板给C++带来了非凡的革命，它能支持群组合作，或者独立运行，范例是无可比拟的。Java由于缺少模板和强制要求任何东西都是对象，而被批评了很长时间。.NET框架在这方面做法一样也很让人失望；可能由于Java缺少模板而他们可以在.NET环境下得到（他们确实达到）让更广的开发团体感到信赖并接受了它。

缺少对RAII的支持对GUIs（通用用户接口）是非常好的，这是在严格的框架内操作的软件——即使象J2EE这样精密复杂和高吞吐量的语言，和非关键的程序。但复杂的软件不必要因为它而复杂。在最好的情况下，到处都是最终模块，只要在Finalize()里函数里添加Close()方法就可以了。在最坏的情况下，滞缓或者随机的资源泄漏都会导致系统的崩溃。更甚于以上的，如果OO（面向对象）——就象C#和Java所有都是对象——是你的目的那更让我不安，第一个要失去的就是对象自己清除自己的责任，我没办法理解这个。（我知道一个非常出名的C++程序员——当然我不能告诉是谁，他告诉我当他在课程中突出RAII和模板的重点时，那些非使用C++的人们露出的滑稽表情，让他感觉好象他丢失了什么东西）

D是使用垃圾回收的语言，默认是非确定性析构,有很多地方与C#和Java相似，但是尽管如此，它还是兼容支持RAII的习惯同时具有模板。并且它是一个人写的！我不明白为什么我们对Java或者C#（.NET其它语言也是一样）印象如此深刻，即使有它们支持RAII和模板的缺点，而我们又能比较这些。有可能C#/.NET成功的原因和Java一样，有大量的，有用的库文件（C和C++应该从中学习，D应该去发展），和有一个强有力的后台。

最后，我想说对于所有的性能结果的比较分析，你必须明智地使用这些结果。我努力使自己公平，选择我相信是公平和有意义的测试。但你一定要判断的出这些例子仅代表了广大可能性的的一小部分（不是无限意义上的），它们不是实际的程序，仅仅是测试而已并且把它简化了，其中不可避免的带有我个人的某种偏见在里面。通过逐步的方法，我希望降低这些因素。但你在阅读和使用这些结果的时候要保持留意。

感谢

我要感谢 Walter Bright提供给我最新的Dv0.62版本，能够完全的测试异常事件。感谢Intel的David Hackson给我提供了C/C++编译器。还要感谢Scott Patterson帮我选择了切合实际的测试方法（他总是不断的在我烦躁、偏题、愚蠢的时候提醒我）。还要感谢Eugene Gershnik 对于我的一些断言给了我严厉的反驳，帮助我适当地注意一些防止误解的说明。

Notes and References

[1] The C++ Programming Language, Bjarne Stroustrup, Addison Wesley, 1997

[2] The Software Optimization Cookbook, Richard Gerber, Intel Press, 2002

[3] Applied Microsoft .NET Framework Programming 1 st Edition, Jeffrey Richter, Microsoft Press, 2002

[4] Described in “ Win32 Performance Measurement Options, ” Matthew Wilson, Windows Developer Network, Volume 2 Number 5, May 2003.

微软发布了 .net 平台和 .net 平台支持的多种语言，包括 C#,vb.net, 受管 (managed extensions) 的 C++. 它们构成的体系能同时满足开发出高效的服务器架构，和开发部门对强壮的多功能的接口的需求．

和其他众多程序员一样，拿新开发语言与日常用到的语言作比较和选择的时候，我对新玩意总有莫名的偏见和怀疑．本篇文章将会讨论 .net 平台的优点，特别是相关的 C#. 我们拿 C# 和其他开发语言在高性能软件开发方面，作定量的性能比较．

因为 c# 程序编译运行分为两部分：先编译成中间代码，然后是中间代码的运行时解释执行，所以我们不仅会把他跟纯编译型的 C/C++/D 语言相比，也会把他与典型的 ( 中间代码运行时解释 ) 的 Java 语言作比较． Java 无疑是一个成熟的语言，应用在各个计算机领域． Java 程序先被编译成中间代码，然后运行时通过 java 虚拟机解释成本地机器码执行．由此看来， .net 平台，特别是为首的 c# 语言，借鉴了 java 的很多东西，包括语法和运行时支持．

对新语言（或者说时语言 + 对应的库 + 该语言的运行时支持）作完整公平的性能比较算是一个庞大考验．本文对 c# 与 C/C++/D 就开发中都涉及到的基本共通点作初步的性能比较，同时还包括各个语言所带的库的性能比较．包括：

1. 运行一次完整的程序（转载执行一个程序的时间）

2. 算法和递归（计算圆周率和 Eratorshnes's sieve ）

3. 类型转换（ int->float,float->int,int->string.string->int ）

4. 字符串比较

5. 字符串连接

6.( 字符串特定符号统计 )

通过上面的一系列比较，将会揭示 c# 编译器效力的一些有意思的地方和 .net 运行库的性能

背景 :

虽然作比较的语言都可以算是 C 语言系列，虽然这五种语言在语法上只有或多或少的不同，但在其他方面，它们的差别是巨大的．（见表一， http://www.digitalmars.com/d/comparison.html ） . 我假设读者已经熟悉 C/C++/Java ，以及一些基本的 C# ．对于 D 语言，不如其他语言那么有名，但你可以找到它的介绍

D 语言介绍

D 语言是 Walter Bright 正在开发的一种语言，安装和学习这种语言的开销很小。实质上， D 语言的目标是更成功的 C/C++ 语言，改进包括可变长度的数组，函数参数的 [in][out] 属性，自动内联，版本控制，局部函数，内建单元测试，严格的类型检查等等，包括 Java/C# 中实现的忽略指针和引用的差别 , 这在 C++ 中只有通过模板实现。它同时支持对现有 C 函数和 API 的直接支持。

它支持许多跟 Java/C# 类似的特性 , 比如垃圾收集。 D 语言跟 C#/Java 的本质区别是 D 语言运行时不需要运行时的虚拟机支持。 D 语言所支持的所有特性都是在编译连接时完成的，所以不需要运行时的额外支持。 D 语言的开发目前已经到了 Alpha 版本，将来的成熟版本在绝大多数情况下将会比 Java/C# 高效得多，除非 JIT 优化非常明显．所以我们才把 D 语言加到我们的测试当中。实际上， Walter 告诉我们， D 完全有能力产生跟 C 代码运行得一样快的代码，同时，由于自动内联，内建数组，字符串内建优化，非 \0 的字符串结束标记等特性，他相信在 D 语言正式发布的时候，它的性能将会超过 C 。

在真正的测试开始以前，我假定性能按照从高到低排序，应该是 C/C++,D,C#,Java ．我跟其随后证实的其他好多人一样，一开始就怀疑 C# 产生高性能代码的能力．

性能比较

我们会在下面接着介绍的十一种不同情况下测试性能．测试平台是 2G 512M 的 pentium4 ，操作系统是 Windows XP Pro. 测试是在一套我自己设计的工具下进行的，为了符合这篇文章，我理所当然地用 C# 写了这个工具。在没有其他干扰进程的情况下，对每个测试者运行七次，分别去掉最快的一次和最慢的一次后得到的品均值，就是测试者的成绩。除了下面说到的 noop 测试，所有的测试通过高精确度定时器计算完成所有内循环所需时间完成。（译者注：比如 int->float 测量中，会通过循环运行多个 int->float 的转换，然后测量完成整个循环需要的时间）。如 Listing1 所示的代码，就是用 c# 完成的 f2i 测试。 (C 通过调用 win32 api 函数 QueryPerformanceCounter() ； C++ 通过 WinSTL 的 performance_counter;C# 通过 SynSoft.Performance.PerformanceCounter;D 通过 syncsoft.win32.perf.PerfomanceCounte ； Java 通过 System.currentTimeMillis()) 。每个程序都包含进入实质测试代码前一段 ” 热身代码 ” 来减少程序初始化 ,catch 等因素带来的不利影响。

编译器版本号如下：

C#:VC#.net v7.00.9466,.NET Framework v1.0.3705;

D: Digital Mars D compiler Alpha v0.61

Java: J2KDSE 1.4.1

C/C++ 在两个编译器下完成，分别是 Digital Mars C/C++ v8.33,STL Port v4.5 和 Inter C/C++ v7.0 ，头文件和库用 VC++ 6.0

用 Digital Mars 编译器的原因是：首先它能快速生成高质量代码，而且免费。其次是为了和 D 语言作比较，因为 D 语言用到相同的 C/C++ 连接器和很多 C 库。

为了作彻底的性能比较，所有的编译器都用了速度最优的优化方案。 Inter 编译选项是 -QaxW ，它提供两种代码路径，一种是专门为 Pentium4+SIMD 优化，一种是为其他 cpu 优化。具体的代码运行路径在运行时自动选择。 ( 通过对不同 C/C++ 编译器性能的分析，我认为 Inter 编译器针对他自己芯片的优化非常好，而对于 Digital Mars 的编译器编译出来的代码性能，可以代表普遍的 C/C++ 性能 )

对这几种语言作方方面面的比较是不太现实的，因为某些特定的功能并没有在这几种语言中都得到实现。比如 C 内建库里没有（字符串特定符号统计）函数。不过既然这篇文章的主题是讨论 C#, 所做的测试都是 C# 支持的，如果其他语言没有提供对应的功能，我们会提供一个自定义的实现。同时，如果某种语言对某种功能的内建支持非常差的话，我会考虑提供一个相对好一点的自定义支持。 ( 特别是对于 C/C++ ，至少有一两个地方看得出效率不高的内建库掩盖了语言本身的真实性能 )

简而言之，我不会列出每种测试在不同语言的具体实现代码，不过在这里，我会详细介绍下面几种测试情况 :

noop.noop 测试的是程序的装载时间 : 一个空的 main/Main 的执行时间。跟其它测试不一样，这个测试是在 ptime 工具下完成的 .( 可以从 http://synesis.com.au/r_systools.html) 　获得，它提供了了 unix 环境下 time 工具类似的功能，同时它还能多次运行目标程序来获得平均值 ( 在我们的测试中， C/C++/D 运行 200 次 ,C# 运行 50 次， java 运行 30 次 ). 为了除去某些特定情况造成的影响，我们会多次测量 ( 译者注：指多次运行 ptime 程序， ptime 程序自身又会多次运行目标程序 ) ，并且取去掉最高值和最低值后的平均值。

f2i 这个测试把 1 个长度为 10,000 的双精度浮点值转换为 32bit 的整数。从 Listing 1 可以看出，使用伪随机数产生算法可以保证各语言比较相同的浮点数。这带来了两个有趣的情况，我们将在查看结果的时候予以讨论。

I2f 跟前一个相反，这个测试对针对具体某个函数进行的测试。程序生成 10000 个确定的伪随机整数，保证在不同语言中被转换的整数是相同的。

I2str 把整型转换成成字符串型。整型变量从 0 循环增加到 5000000 ，每次做一个整型到字符串型的转换 ( 见 listing2).C#/Java 用内建函数完成 ---i.ToString() 和 Integer.Tostring(i),C/D 用传统的 sprintf() 完成。 C++ 分为两次完成。第一次用 iostream 的 strstream 类，和预期的一样，这种情况下的性能非常差。为了提高效率，我采取了一些措施，所以导致了第二种方案，见 i2str2

Str2i. 把字符串转换成整型。建立一个字符串数组，内容是 i2str 转换过来的内容，然后再通过语言本身的支持或者库函数把字符串转换回去，计算转换回去的时间（见 listing3 ） .C/D 用 atoi 完成， c++ 用 iostream 的 strstream 完成， c# 用 int32.parse 完成， java 用 integer.parseint() 完成。

picalc 迭代和浮点。通过 listing 4 所示的迭代算法计算圆周率。每种语言的实现其迭代次数是 10,000,000 。

Picalcr. 递归。通过 listing5 所示的算法计算圆周率。对每种语言，我们会做 10000 次运算，考虑到 java 堆栈在深层地归时很容易被耗尽，所以每次运算限制在 4500 次递归以内。

Sieve. 叠代。通过 Listing 6 所示的迭代算法（ Eratosthenes's sieve （ http://www.math.utah.edu/~alfeld/Eratorthenes.html ））得到质数。每种语言的实现其迭代次数是 10,000,000 。

Strcat. 字符串连接 --- 通常是大量运行时开销的根源，也是导致程序低效的潜在领域。（我以前做过一个对性能敏感的项目，通过改善效率底下的字符串连接，我获得了 10% 的整体性能提升） . 测试通过构造四种不同类型的变量 :short,int, double 和一个 string ，然后把它们连接成一个 string 变量完成，连接时添加用分号分割．在连接的时候采用四种不同的连接方

法 :1) 默认连接方法 2) 故意构造出来的导致效率低下的连接方法 3)C 语言种典型的 printf/Format 格式，需要重新分配空间 4) 为提高性能而进行的硬编码 . 代码摘录见 Listing7

Strswtch. 通过级联 switch 进行字符串比较 . 通过语言支持的 switch 语句进行比较或者通过一些列的 if-else 语句模拟（ Listing 8 ）．这项测试是为了检验 c# 的字符串处理功能是否如他所声称的那样高效．测试分成两部分 : 首先是进行字符串之间的赋值，也就是同一身份的比较（译者注：也就是字符串内部的指针直接复制，不涉及到字符串内容的拷贝）．其次是通过字符串的拷贝后进行比较，这样就避免了同一身份比较而是进行进行字符串之间的字面比较．每种语言上都进行 850000 次叠代，因为超过这个次数后会导致 java vm 内存耗尽．

strtok 字符串分段。字符串的运行效率也极低，有时甚至引发严重的运行开销。这个测试（ Listing 9）读取一个文本文件的全部内容至一个字符串，然后拆分成段。第一个变量用字符分隔符：‘；'分隔字符串，并忽略所有的空白。第二个变量也用分号分隔，但保留了空白。第三个和第四个变量用字符串分隔符：<->，并相应的忽略和保留了空白处。C里仅第二个变量用了strtok()，C++四个变量都用STLSoft的string_tokeniser模板，但各自正确给参数赋值。C#第一个变量用System.String.Split()，2至4变量用SynSoft.Text.Tokeniser.Tokenise()；Java用java.util.StringTokenizer，仅支持变量2和4（注：我选用STLSoft的string_tokeniser模板不是我要为STLSoft作宣传，而是测试表明它比Boost的快2.5倍，而Boost是大多数开发人员在查找库时的首选）。

结果

在 noop测试中，表2列出了以微秒（us）为单位装载一个空操作的平均开销。显然C，C++，D的差别不合逻辑，每一个大约是5-6毫秒，而Intel确低至2ms。我所想到的唯一可能是这个编译器优化了所有的C实时运行库的初始化工作。如果是这样，这个性能在其他非试验性即实际应用中不能体现出来，因为它至少需要一些C … ，这有待深入研究。

C#用了大约70ms，Java约0.2秒。C#和Java的装载清晰的表明其实时开销在于它们的实时运行的结构基础（VM和支持DLLs）。但是除了大规模的命令行的商业化批处理，对极大型系统（上百万条代码）或CGI的基础构建，启动开销在大多数情况下不重要。重荷服务器允许在数秒内启动，所以语言间200ms的差异就微乎其微了。

其余的结果分三部分显示。图 2和3分别展示了字符串连接和分段的结果。图1包含了其余全部的测试结果，我们现在先来看看它。

图 1中，对各测试项，C，C++，D，Java的结果均以其相应测试项C＃运行时间的百分比显示。因此，在100%线上下波动的结果说明与C＃性能相当。高百分比说明C#性能较优，而低百分比表明C#性能相对较差。

f2i 抛开Intel不谈，可以看出C#在浮点到整型的转换中效率远远高于其余四个，仅是C，C++， 和D开销的2/3,是Java的2/5。在我让它们使用相同的随机数发生器前，不同语言的性能差异极大，这说明转换速度非常依赖具体的浮点数值，当然这是后见之明了。为了确保每个语言做相同的转换，程序计算转换值的总和，这也有助于任何过度的优化去除整个循环。可以得知这种转化在语言间正确度不同。每种语言的计算总和迭代10,000次的结果在表3中列处。它们表明（虽然无法证实）C，C++，和D是最正确的，Java其次，C#最差。C#牺牲正确性和降低处理器浮点精度（参见 引用）换取优越性能是令人信服的，但事实上做此判断前我还需要更多的证据。至于Intel，说它的性能没有什么更卓越的也是公平的。

5个语言这里效率相当。另4种性能比C#低5%以内。唯一叫人感兴趣的是这四个语言都是性能比C#略好。这表明C#确实效率低，虽然在这方面只低一点。这与从整型到浮点型转换的结果相反。同样，值得我们注意的是，虽然Java在浮点到整型的转换中性能很低，但在整型到浮点的转换中却是最好的，比C#高10%。对f2i，Intel表现极佳，其C和C++分别只用了C#时间的10%和23%。

i2str 整型到字符型的转换。 C#比C和D的printf略好。比C++的以iostream为基础的转换效率要高。它是C#运行时间的4倍（对Intel 和VC6 STL/CRT是5倍）。但Java性能出色，用了C#2/5的时间。因为C++的效率低下，第二个变量使用STLSoft的 integer_to_string<> 模板函数。它在很多编译器上比C和C++库的所有可利用的转换机制要快。在这种情况下，性能比C#高10%，比C和D高约20%。但是因为Intel编译器的优化影响， integer_to_string<> 似乎找到了其完美搭档：其时间比C#低30%，是第三个速度超过Java的，比Iostream快17倍以上。认为它很可能已经接近了转换效率的上限也是合理的。

str2i 字符型到整型的转化结果与前面大相径庭。 C和D用atoi比C#快约5-8倍，比Java快3倍，Java比C#效率高得多。但是这四个比C++以iostream为基础的转换都快。C++用 Digital Mars/STLPor运行时间t 是 C#的2.5倍，用 Intel和VC6 CRT/STL 是 10倍。这是iostream的另一个致命弱点。但因此说C++效率低下未免有失公允（实际上，我正在为 STLSoft 库写字符至整型的转换，以和它 integer_to_string<> 的杰出转换性能相匹配。最初的结果表明它将优于 C的atoi，所以这个转换中C++也是优于C的。我希望能在本文刊发前完成此转换。请参阅 http://stlsoft.org/conversion_library.html 。 ）

picalc 在这里各语言性能表现相近。 C#和Java几乎相同，比C，C++效率高上10%。C#的性能可以这样解释：它的浮点数操作效率高，这可以从f2I看出。但这不能理解Java的表现。我们可以认为C#和Java都能较好的优化循环，它涉及函数调用，但这有赖于深入研究。既然性能相差10%以内，我们只能得出这样的结论：各语言在循环结构性能方面差异不显著。有趣的是，Intel的优化这里没有实际效果，可能是因为Pi值计算太简单了吧。

Picalcr : 这里的结果可以更加确定一点， C ， C++ ， C# 和 D 语言的性能偏差在 2% 之内，我们可以公平地说它们对于递归执行的性能是一样的。 Java 却是花费比其他四种语言多 20% 的时间，加上 JVM （ Java 虚拟机）在超过 4500 次递归时堆栈耗竭，可以明显地从速度和内存消耗方面得出 Java 处理递归不是很好。 Intel 的优化能力在这里有明显的作用（让人印象深刻的 10% ），但我在这里并没有详细分析这一点。

Sieve: 相对简单的计算质数的算法（仅包含迭代和数组访问）说明 C ， C++ ， C# 和 D 语言在这方面事实上是一样的（仅 0.5% 的偏差），但 Java 的性能低了 6% 。我认为这中间大有文章， C ， C++ 代码不进行数组边界安全检查，而 C# 和 Java 进行数组边界检查。我对这种结果的解释是： C# 和 D 语言在 FOR 循环内能根据对数组边界的条件测试对边界检查进行优化，而 Java 不行。由于 C# 是新兴语言， D 语言还没发行，这就让人不那么失望了。即使这不是为 Java 辩解，也不会让人印象深刻了。再说， Intel 优化起了明显的作用——增长 5% 性能，正如 picalcr 例子，这相对于其他语言更让人印象深刻。

Strswtch : 这个测试对于 C# 语言不是很好。即使是 C++ 低效的字符串类操作符 = = 都比 C# 的性能快 2.5 倍 (Digital Mars) 到 5 倍（ Intel VC6 STL/CRT ）。 .NET 环境下字符串是内部处理的，这表示字符串存储在全局离散表中，副本可以从内存中消除，等值测试是以一致性检查的方式进行的 ( 只要两个参数都是在内部 ) 。这明显表示内部修复机制的效率严重低下或者一致性检查没有建立 C# 的 ”string-swatching” 机制性。 C# 的这种严重低效率更让人倾向于后者，因为想不到个好的理由解释为什么会这样。正如例 8 所示，变量 1 的字符串实例是文字的，都在内部（事实上，这里有个限制没有在例 8 中表示出来，在变量 1 的预循环中用来验证参数是真正在内部的）。

当在变量 2 中假装进行一致性检查，发现仅 Java 的性能有明显的提高，从 2% 到令人印象深刻的 30% 。很明显 Java 在使用一致性检查所取的性能是不切实际的，因为在真正的程序中不能限制字符串都是文字的。但这可用来说明支持内部处理和提供可编程实现访问这种机制的语言的一种性能。讽刺的是， C# 作为这五种语言之一，它的性能是最差的。

Strcat : 表 2 以微秒（ μs ）显示了五种语言每一种在这个例子中的四个变量的花费时间。本文没有足够的篇幅来细节描述 17 执行代码，但尽量保持例子 7 的四个变量的真实面貌。变量 1 和 2 在所有语言执行代码中涉及以堆栈为基础的字符串内存，同时 C ， D 语言在第三个变量中、 C ， C++ ， D 语言在第四个变量中用结构内存，这在某种程度说明他们的性能优于其他变量和语言的执行代码。本例子的 C ， C++ 的讨论适合于 Digital Mars 版本，因为很明显的 Intel 所带来的性能提高被 Visual C++ 运行时刻库的效率（非期望）所抵消，事实上 Intel 的每种测试的性能都比 Digital Mars 的差。

第一种测试是以默认的方式执行的，很显然 C# 和 D 语言的性能都好于其它语言。很奇怪的是 Java 的性能最差，因为 Java 被认为有能力在一条语句中把字符串序列解释成字符串构件格式（在变量 4 中手工转换）。

第二种测试，众所周知它的格式不好，透露了很多东西。它的劣性根据语言而不同，对于 C# ， D 和 Java ，包含在连续的表达式中连接每一项，而不是象第一个变量在一个表达式中。对于 C ，它简单地省略了在开始多项连接重新分配之前的的内存请求。对于 C++ ，它使用 strstream 和插入操作符而不是使用 str::string 和 + （）操作符。结果显示所有语言不同程度地降低性能。 C 内存分配器的附加轮询看起来没有起多大作用，可能因为没有竞争线程造成内存碎片，所以消耗同样的内存块。 C++ 改变成 iostreams 使代码更紧凑，但没有转变数字部分，它们仅被插入到流当中，所预计的执行结果验证了这一点。 D 因为这个改变降低性能许多（ 32% ）， Java 更多（ 60% ）。很奇怪的是 C# 性能在这里仅降低很小，少于 7% 。这让人印象非常深刻，意味着可能在 .NET 的开发环境下因为 Java 字符串连接而形成的代码回查的警觉本能会衰退。

第三种测试使用 printf()/Format() 的变量不足为奇。通过使用部分 / 全部的帧内存， C ， C++ 和 D 达到很好的性能。奇怪的是 C# 的性能仅是 22% ，简直不值一提。 Java 根本没有这个便利功能。（以个人的观点也是不值一提的） C#和D语言都能够在封闭的循环中，依照数组边界测试情况，优化他们的越界检查。

最大的 测试 －硬编码的性能－这个是很有趣的问题，因为 C++还是能提供超级的性能，如果能够依照问题的精确领域来编码，即使别的语言（C#,java）使用默认的或者性能优化的组件或者理念也是如此。在C#和java上使用他们各自的StringBuilders能够提供真实的效果，达到他们在这个集合中的最佳性能。然而，C#能发挥最佳效率的机制，还是不能与C/C++、D语言相比。更糟糕的是，java的最佳性能都比别的语言的最差性能要可怜，这是相当可悲的。

总之，我们说对底层直接操作的语言垂手可得地赢得那些转化率工作得很好的或者完全地在中间代码中，并且很显然地能够提供良好性能的语言用法对java是很重要的而对C#是不太重要的。请注意这一点。

Strtok . Table3显示了五种语言的每一个环节总共的时间（单位是毫秒ms）。同时他们的空间占用在这篇文章中并没有提及，但是所有语言的实现都是非常直接的并且很明显很接近在Listing9中列出的四个问题的本质。与strcat一样，基于同样的原因，使用Intel编译器的结果没有讨论。

第一个问题――分割字符，保留空格――显示C++版本是明显的胜利者，D语言要慢20％，C# 要3倍的时间。显然，这个与库的特征的关系比语言的更明显，

并且我使用 tokenizer比著名的Boost更多一些，那样的话，D语言要比C++快2倍，并且C＃只慢20％。虽然如此，STLSoft的tokenizer是免费得到,我想我们应该把这个作为C++的一个胜利。（其实，template在这一点上的使用STL的basic_string作为他的值类型，这个并不因为他的良好性能而闻名，这可能引起争论－我并没有使用一个更有效率的string，就像STLSoft的frame_string.总之，我认为这是个公平比较）。

第二个问题－－分割字符，去掉空格－－包含所有语言的实现版本。自然地，C语言赢得了比赛，它使用了strtok()函数，这个函数在创建tokens时并不分配内存并且直接写终结符NULL到tokenized string的结尾。尽管有这些不利条件，C++的性能还是很好的，时间是C的221％，比较好的是D语言，432％。

C＃和java就很差了，分别是746％和957％。这简直是不敢相信的，C＃和java运行的时间是C++的3.4倍和4.3倍，这三种语言都为tokens分配了内存。我相信这个是STL模型在处理iterable sequences时比passing around arrays更有效率的很好的例子。（请注意，我们有高度的信心这是场公平的关于C++,C#和D语言的比较，我写了三种tokerizer的实现，都是公开的，可得到的.)

第三个问题－－分割句子，保留空格--显示了两件事情。第一，在这三种语言在实现这个程序的代价比实现单个字符更昂贵。第二，我们发现D语言取代了C++的最佳性能的地位，领先5％左右。C＃继续被甩下，大概是另外两种语言的1.8倍时间左右。

第四个问题－－分割句子，去掉空格--没有任何令人意外的，C++和D拥有大概一致的性能。C＃比较不错（大概2倍的性能差距）java更慢（差不多3倍时间）。对于C++，C＃和D来说去掉空格比不去掉空格导致一小点的性能损失。很明显的，在C＃中，这么做比其他两个的损失更大一点。很有价值的是，这些功能在C＃和D中是已经实现的。由于数组在C#中是不可变的，从tokens中返回一个没有空格的数组将导致重新分配一个数组。可是，D允许指派数组的长度，这个能动态地调整数组的大小这是个很好的例子说明D语言提供更好的效率。

总的来说，考虑到性能和自由度，我们能够说 C++是胜利者，D是很接近的第二名。C拥有最佳的性能，但是只支持一种类型的tokerization。C＃表现得很差，java更甚。

总结

我们可以把结果分成3种情况：这些包括语言的特性，包括库的特性，或者两者都相关。这些只与语言相关的特性显示在 f2i, i2f, picalc, picalcr, and sieve scenarios,这些在语言选择上的作用是很小的。c＃看起来在总体上是最好的，但是有点让人不能信服的是它在f2i中取得的优异性能并且是因为牺牲了浮点精确度而取得效率。（这一点需要更多大检查，我将在下一篇文章中去做。）

java是明显最差的 。

当讨论intel编译器的浮点计算的深度优化效果时，它很明显地显示，c和c++能够做的比C＃更好。我讨论这些并不是说这些语言必须要更好的效率，而是说他们能比其他的语言提供更好的优化和增强的机会。这个大概是与本主题完全不相干的是，C和C++比别的语言有更多的编译器；更多的竞争，更聪明的人拥有不同的策略和技术。编译器的结果的运行目标是处理器，这将导致戏剧性的效果；我们仅仅在表面上探讨了这个庞大的问题，但是我不久将在以后的文章中回到这个主题。

Strtok 是唯一一个能说是library-only的，在这一点上C＃干的并不好。虽然比java快，但是比其他的语言慢2倍或更多。同样令人失望的是VisualC/C++的运行库。在这一点上包括语言和库的效果的是i2str,str2i,strcat和strtswtch，描绘的并不是很清楚。C＃明显的在string的拼接这一环节上比java好得多，但是明显地比其他的差。关于尊敬的C，C++,D，只是在一些环节上领先，在另外一些环节上相当地差。

很有趣的是定制的C++的库替换加上深度优化的intel的编译器。

总之，不可能做出定量的结论。从语言的表层来看， C# 和 Java 挺简单的，但低效的库降低了速度。我觉得，当相关的库还不如语言本身的时候， C# 的确实有微弱的优势；但反过来，当库逐渐完善，超过语言本身后， C# 明显就不行了。但还是能看到一点点希望： C# 还是有可能实现预期的目标，因为库比语言更容易实现组装。但是，人们认为由于跟别的语言相比， C# 和 Java 所用的库与语言结合的更加紧密，这些库就可以作为这两种语言效率的关键所在，至少对当前的版本来说是这样的。

正如我所作出的示范（从整数到字符）以及相关提到的（从字符到整数），有人可能会批评者并不符合这篇文章的原意。

更深入的探讨

本文主要探讨了一下 C# 对 C++ 和 Java 可能造成的“威胁”。总的来说，这结果虽然不怎么鼓舞人心，却足以让人吃惊。从效率上看， C# 跟 C 以及 C++ 这些过去的同类产品（假如它们是更高效的）相比只能算是一般水平，至少在基本语言特征的比较上是这样的。从某种程度上来说， Java 也是如此。（我承认我无法证明 C 和 C++ 相对于 C# 的绝对优势。在多年前我的毕业论文分析调查期间，我认识到令人乏味的结果正和令人兴奋的结果一样生动形象，但前者花费更小的经济支出。）

上述结论对于多处理器以及（高性能的文件／网络处理系统）等来说却不一定适用。不过，这确实很好地展现出了这些语言的基本效率以及更复杂的运算所依赖的最基本的库。

就 D 发展状况来看，现在就对它进行这样的归类似乎为时过早，不过它现在的表现确实不错。 D 的效率至少是 C# 的 167% ，其实大多数情况下还不止。有些人指出，目前仅仅还处于字符时代，只需几个人就能完成一个编译器及其附带的库。我猜测， D 有可能发展成一门强大的技术。

就我个人而言，作为一个对 C# 持有偏见的人，偶然还是会对它的性能感到惊讶。我热切地期盼着能将性能的对比分析延伸到更多领域：复杂而高效的内存的应用，多线程，进程通信，特殊文件处理，手写代码开销，这些技术都能让我们对语言进行更深入的研究。能看到 Inter 公司怎样通过定制的 C Library （比如 CRunTiny ；参考 http://cruntiny.org/ ）和 STL （比如 STLPort ）。

鸣谢

感谢 Walter Bright 为我提供了一份言简意赅的关于 D 的介绍，并及时地指出了一些当时被我忽略的优点，使我能对测试工程进行改进。同时也要感谢 Sun Microsystems 公司的 Gary Pennington ，他为我提供了关于 Java 方面的资料。还有 Scott Patterson ，他对本文的草稿进行了大量的精简，并对全篇文章进行了细致的检查。

微软发布了 .net 平台和 .net 平台支持的多种语言，包括 C#,vb.net, 受管 (managed extensions) 的 C++. 它们构成的体系能同时满足开发出高效的服务器架构，和开发部门对强壮的多功能的接口的需求．

和其他众多程序员一样，拿新开发语言与日常用到的语言作比较和选择的时候，我对新玩意总有莫名的偏见和怀疑．本篇文章将会讨论 .net 平台的优点，特别是相关的 C#. 我们拿 C# 和其他开发语言在高性能软件开发方面，作定量的性能比较．

因为 c# 程序编译运行分为两部分：先编译成中间代码，然后是中间代码的运行时解释执行，所以我们不仅会把他跟纯编译型的 C/C++/D 语言相比，也会把他与典型的 ( 中间代码运行时解释 ) 的 Java 语言作比较． Java 无疑是一个成熟的语言，应用在各个计算机领域． Java 程序先被编译成中间代码，然后运行时通过 java 虚拟机解释成本地机器码执行．由此看来， .net 平台，特别是为首的 c# 语言，借鉴了 java 的很多东西，包括语法和运行时支持．

对新语言（或者说时语言 + 对应的库 + 该语言的运行时支持）作完整公平的性能比较算是一个庞大考验．本文对 c# 与 C/C++/D 就开发中都涉及到的基本共通点作初步的性能比较，同时还包括各个语言所带的库的性能比较．包括：

1. 运行一次完整的程序（转载执行一个程序的时间）

2. 算法和递归（计算圆周率和 Eratorshnes's sieve ）

3. 类型转换（ int->float,float->int,int->string.string->int ）

4. 字符串比较

5. 字符串连接

6.( 字符串特定符号统计 )

通过上面的一系列比较，将会揭示 c# 编译器效力的一些有意思的地方和 .net 运行库的性能

背景 :

虽然作比较的语言都可以算是 C 语言系列，虽然这五种语言在语法上只有或多或少的不同，但在其他方面，它们的差别是巨大的．（见表一， http://www.digitalmars.com/d/comparison.html ） . 我假设读者已经熟悉 C/C++/Java ，以及一些基本的 C# ．对于 D 语言，不如其他语言那么有名，但你可以找到它的介绍

D 语言介绍

D 语言是 Walter Bright 正在开发的一种语言，安装和学习这种语言的开销很小。实质上， D 语言的目标是更成功的 C/C++ 语言，改进包括可变长度的数组，函数参数的 [in][out] 属性，自动内联，版本控制，局部函数，内建单元测试，严格的类型检查等等，包括 Java/C# 中实现的忽略指针和引用的差别 , 这在 C++ 中只有通过模板实现。它同时支持对现有 C 函数和 API 的直接支持。

它支持许多跟 Java/C# 类似的特性 , 比如垃圾收集。 D 语言跟 C#/Java 的本质区别是 D 语言运行时不需要运行时的虚拟机支持。 D 语言所支持的所有特性都是在编译连接时完成的，所以不需要运行时的额外支持。 D 语言的开发目前已经到了 Alpha 版本，将来的成熟版本在绝大多数情况下将会比 Java/C# 高效得多，除非 JIT 优化非常明显．所以我们才把 D 语言加到我们的测试当中。实际上， Walter 告诉我们， D 完全有能力产生跟 C 代码运行得一样快的代码，同时，由于自动内联，内建数组，字符串内建优化，非 \0 的字符串结束标记等特性，他相信在 D 语言正式发布的时候，它的性能将会超过 C 。

在真正的测试开始以前，我假定性能按照从高到低排序，应该是 C/C++,D,C#,Java ．我跟其随后证实的其他好多人一样，一开始就怀疑 C# 产生高性能代码的能力．

性能比较

我们会在下面接着介绍的十一种不同情况下测试性能．测试平台是 2G 512M 的 pentium4 ，操作系统是 Windows XP Pro. 测试是在一套我自己设计的工具下进行的，为了符合这篇文章，我理所当然地用 C# 写了这个工具。在没有其他干扰进程的情况下，对每个测试者运行七次，分别去掉最快的一次和最慢的一次后得到的品均值，就是测试者的成绩。除了下面说到的 noop 测试，所有的测试通过高精确度定时器计算完成所有内循环所需时间完成。（译者注：比如 int->float 测量中，会通过循环运行多个 int->float 的转换，然后测量完成整个循环需要的时间）。如 Listing1 所示的代码，就是用 c# 完成的 f2i 测试。 (C 通过调用 win32 api 函数 QueryPerformanceCounter() ； C++ 通过 WinSTL 的 performance_counter;C# 通过 SynSoft.Performance.PerformanceCounter;D 通过 syncsoft.win32.perf.PerfomanceCounte ； Java 通过 System.currentTimeMillis()) 。每个程序都包含进入实质测试代码前一段 ” 热身代码 ” 来减少程序初始化 ,catch 等因素带来的不利影响。

编译器版本号如下：

C#:VC#.net v7.00.9466,.NET Framework v1.0.3705;

D: Digital Mars D compiler Alpha v0.61

Java: J2KDSE 1.4.1

C/C++ 在两个编译器下完成，分别是 Digital Mars C/C++ v8.33,STL Port v4.5 和 Inter C/C++ v7.0 ，头文件和库用 VC++ 6.0

用 Digital Mars 编译器的原因是：首先它能快速生成高质量代码，而且免费。其次是为了和 D 语言作比较，因为 D 语言用到相同的 C/C++ 连接器和很多 C 库。

为了作彻底的性能比较，所有的编译器都用了速度最优的优化方案。 Inter 编译选项是 -QaxW ，它提供两种代码路径，一种是专门为 Pentium4+SIMD 优化，一种是为其他 cpu 优化。具体的代码运行路径在运行时自动选择。 ( 通过对不同 C/C++ 编译器性能的分析，我认为 Inter 编译器针对他自己芯片的优化非常好，而对于 Digital Mars 的编译器编译出来的代码性能，可以代表普遍的 C/C++ 性能 )

对这几种语言作方方面面的比较是不太现实的，因为某些特定的功能并没有在这几种语言中都得到实现。比如 C 内建库里没有（字符串特定符号统计）函数。不过既然这篇文章的主题是讨论 C#, 所做的测试都是 C# 支持的，如果其他语言没有提供对应的功能，我们会提供一个自定义的实现。同时，如果某种语言对某种功能的内建支持非常差的话，我会考虑提供一个相对好一点的自定义支持。 ( 特别是对于 C/C++ ，至少有一两个地方看得出效率不高的内建库掩盖了语言本身的真实性能 )

简而言之，我不会列出每种测试在不同语言的具体实现代码，不过在这里，我会详细介绍下面几种测试情况 :

noop.noop 测试的是程序的装载时间 : 一个空的 main/Main 的执行时间。跟其它测试不一样，这个测试是在 ptime 工具下完成的 .( 可以从 http://synesis.com.au/r_systools.html) 　获得，它提供了了 unix 环境下 time 工具类似的功能，同时它还能多次运行目标程序来获得平均值 ( 在我们的测试中， C/C++/D 运行 200 次 ,C# 运行 50 次， java 运行 30 次 ). 为了除去某些特定情况造成的影响，我们会多次测量 ( 译者注：指多次运行 ptime 程序， ptime 程序自身又会多次运行目标程序 ) ，并且取去掉最高值和最低值后的平均值。

f2i 这个测试把 1 个长度为 10,000 的双精度浮点值转换为 32bit 的整数。从 Listing 1 可以看出，使用伪随机数产生算法可以保证各语言比较相同的浮点数。这带来了两个有趣的情况，我们将在查看结果的时候予以讨论。

I2f 跟前一个相反，这个测试对针对具体某个函数进行的测试。程序生成 10000 个确定的伪随机整数，保证在不同语言中被转换的整数是相同的。

I2str 把整型转换成成字符串型。整型变量从 0 循环增加到 5000000 ，每次做一个整型到字符串型的转换 ( 见 listing2).C#/Java 用内建函数完成 ---i.ToString() 和 Integer.Tostring(i),C/D 用传统的 sprintf() 完成。 C++ 分为两次完成。第一次用 iostream 的 strstream 类，和预期的一样，这种情况下的性能非常差。为了提高效率，我采取了一些措施，所以导致了第二种方案，见 i2str2

Str2i. 把字符串转换成整型。建立一个字符串数组，内容是 i2str 转换过来的内容，然后再通过语言本身的支持或者库函数把字符串转换回去，计算转换回去的时间（见 listing3 ） .C/D 用 atoi 完成， c++ 用 iostream 的 strstream 完成， c# 用 int32.parse 完成， java 用 integer.parseint() 完成。

picalc 迭代和浮点。通过 listing 4 所示的迭代算法计算圆周率。每种语言的实现其迭代次数是 10,000,000 。

Picalcr. 递归。通过 listing5 所示的算法计算圆周率。对每种语言，我们会做 10000 次运算，考虑到 java 堆栈在深层地归时很容易被耗尽，所以每次运算限制在 4500 次递归以内。

Sieve. 叠代。通过 Listing 6 所示的迭代算法（ Eratosthenes's sieve （ http://www.math.utah.edu/~alfeld/Eratorthenes.html ））得到质数。每种语言的实现其迭代次数是 10,000,000 。

Strcat. 字符串连接 --- 通常是大量运行时开销的根源，也是导致程序低效的潜在领域。（我以前做过一个对性能敏感的项目，通过改善效率底下的字符串连接，我获得了 10% 的整体性能提升） . 测试通过构造四种不同类型的变量 :short,int, double 和一个 string ，然后把它们连接成一个 string 变量完成，连接时添加用分号分割．在连接的时候采用四种不同的连接方

法 :1) 默认连接方法 2) 故意构造出来的导致效率低下的连接方法 3)C 语言种典型的 printf/Format 格式，需要重新分配空间 4) 为提高性能而进行的硬编码 . 代码摘录见 Listing7

Strswtch. 通过级联 switch 进行字符串比较 . 通过语言支持的 switch 语句进行比较或者通过一些列的 if-else 语句模拟（ Listing 8 ）．这项测试是为了检验 c# 的字符串处理功能是否如他所声称的那样高效．测试分成两部分 : 首先是进行字符串之间的赋值，也就是同一身份的比较（译者注：也就是字符串内部的指针直接复制，不涉及到字符串内容的拷贝）．其次是通过字符串的拷贝后进行比较，这样就避免了同一身份比较而是进行进行字符串之间的字面比较．每种语言上都进行 850000 次叠代，因为超过这个次数后会导致 java vm 内存耗尽．

strtok 字符串分段。字符串的运行效率也极低，有时甚至引发严重的运行开销。这个测试（ Listing 9）读取一个文本文件的全部内容至一个字符串，然后拆分成段。第一个变量用字符分隔符：‘；'分隔字符串，并忽略所有的空白。第二个变量也用分号分隔，但保留了空白。第三个和第四个变量用字符串分隔符：<->，并相应的忽略和保留了空白处。C里仅第二个变量用了strtok()，C++四个变量都用STLSoft的string_tokeniser模板，但各自正确给参数赋值。C#第一个变量用System.String.Split()，2至4变量用SynSoft.Text.Tokeniser.Tokenise()；Java用java.util.StringTokenizer，仅支持变量2和4（注：我选用STLSoft的string_tokeniser模板不是我要为STLSoft作宣传，而是测试表明它比Boost的快2.5倍，而Boost是大多数开发人员在查找库时的首选）。

结果

在 noop测试中，表2列出了以微秒（us）为单位装载一个空操作的平均开销。显然C，C++，D的差别不合逻辑，每一个大约是5-6毫秒，而Intel确低至2ms。我所想到的唯一可能是这个编译器优化了所有的C实时运行库的初始化工作。如果是这样，这个性能在其他非试验性即实际应用中不能体现出来，因为它至少需要一些C … ，这有待深入研究。

C#用了大约70ms，Java约0.2秒。C#和Java的装载清晰的表明其实时开销在于它们的实时运行的结构基础（VM和支持DLLs）。但是除了大规模的命令行的商业化批处理，对极大型系统（上百万条代码）或CGI的基础构建，启动开销在大多数情况下不重要。重荷服务器允许在数秒内启动，所以语言间200ms的差异就微乎其微了。

其余的结果分三部分显示。图 2和3分别展示了字符串连接和分段的结果。图1包含了其余全部的测试结果，我们现在先来看看它。

图 1中，对各测试项，C，C++，D，Java的结果均以其相应测试项C＃运行时间的百分比显示。因此，在100%线上下波动的结果说明与C＃性能相当。高百分比说明C#性能较优，而低百分比表明C#性能相对较差。

f2i 抛开Intel不谈，可以看出C#在浮点到整型的转换中效率远远高于其余四个，仅是C，C++， 和D开销的2/3,是Java的2/5。在我让它们使用相同的随机数发生器前，不同语言的性能差异极大，这说明转换速度非常依赖具体的浮点数值，当然这是后见之明了。为了确保每个语言做相同的转换，程序计算转换值的总和，这也有助于任何过度的优化去除整个循环。可以得知这种转化在语言间正确度不同。每种语言的计算总和迭代10,000次的结果在表3中列处。它们表明（虽然无法证实）C，C++，和D是最正确的，Java其次，C#最差。C#牺牲正确性和降低处理器浮点精度（参见 引用）换取优越性能是令人信服的，但事实上做此判断前我还需要更多的证据。至于Intel，说它的性能没有什么更卓越的也是公平的。

5个语言这里效率相当。另4种性能比C#低5%以内。唯一叫人感兴趣的是这四个语言都是性能比C#略好。这表明C#确实效率低，虽然在这方面只低一点。这与从整型到浮点型转换的结果相反。同样，值得我们注意的是，虽然Java在浮点到整型的转换中性能很低，但在整型到浮点的转换中却是最好的，比C#高10%。对f2i，Intel表现极佳，其C和C++分别只用了C#时间的10%和23%。

i2str 整型到字符型的转换。 C#比C和D的printf略好。比C++的以iostream为基础的转换效率要高。它是C#运行时间的4倍（对Intel 和VC6 STL/CRT是5倍）。但Java性能出色，用了C#2/5的时间。因为C++的效率低下，第二个变量使用STLSoft的 integer_to_string<> 模板函数。它在很多编译器上比C和C++库的所有可利用的转换机制要快。在这种情况下，性能比C#高10%，比C和D高约20%。但是因为Intel编译器的优化影响， integer_to_string<> 似乎找到了其完美搭档：其时间比C#低30%，是第三个速度超过Java的，比Iostream快17倍以上。认为它很可能已经接近了转换效率的上限也是合理的。

str2i 字符型到整型的转化结果与前面大相径庭。 C和D用atoi比C#快约5-8倍，比Java快3倍，Java比C#效率高得多。但是这四个比C++以iostream为基础的转换都快。C++用 Digital Mars/STLPor运行时间t 是 C#的2.5倍，用 Intel和VC6 CRT/STL 是 10倍。这是iostream的另一个致命弱点。但因此说C++效率低下未免有失公允（实际上，我正在为 STLSoft 库写字符至整型的转换，以和它 integer_to_string<> 的杰出转换性能相匹配。最初的结果表明它将优于 C的atoi，所以这个转换中C++也是优于C的。我希望能在本文刊发前完成此转换。请参阅 http://stlsoft.org/conversion_library.html 。 ）

picalc 在这里各语言性能表现相近。 C#和Java几乎相同，比C，C++效率高上10%。C#的性能可以这样解释：它的浮点数操作效率高，这可以从f2I看出。但这不能理解Java的表现。我们可以认为C#和Java都能较好的优化循环，它涉及函数调用，但这有赖于深入研究。既然性能相差10%以内，我们只能得出这样的结论：各语言在循环结构性能方面差异不显著。有趣的是，Intel的优化这里没有实际效果，可能是因为Pi值计算太简单了吧。

Picalcr : 这里的结果可以更加确定一点， C ， C++ ， C# 和 D 语言的性能偏差在 2% 之内，我们可以公平地说它们对于递归执行的性能是一样的。 Java 却是花费比其他四种语言多 20% 的时间，加上 JVM （ Java 虚拟机）在超过 4500 次递归时堆栈耗竭，可以明显地从速度和内存消耗方面得出 Java 处理递归不是很好。 Intel 的优化能力在这里有明显的作用（让人印象深刻的 10% ），但我在这里并没有详细分析这一点。

Sieve: 相对简单的计算质数的算法（仅包含迭代和数组访问）说明 C ， C++ ， C# 和 D 语言在这方面事实上是一样的（仅 0.5% 的偏差），但 Java 的性能低了 6% 。我认为这中间大有文章， C ， C++ 代码不进行数组边界安全检查，而 C# 和 Java 进行数组边界检查。我对这种结果的解释是： C# 和 D 语言在 FOR 循环内能根据对数组边界的条件测试对边界检查进行优化，而 Java 不行。由于 C# 是新兴语言， D 语言还没发行，这就让人不那么失望了。即使这不是为 Java 辩解，也不会让人印象深刻了。再说， Intel 优化起了明显的作用——增长 5% 性能，正如 picalcr 例子，这相对于其他语言更让人印象深刻。

Strswtch : 这个测试对于 C# 语言不是很好。即使是 C++ 低效的字符串类操作符 = = 都比 C# 的性能快 2.5 倍 (Digital Mars) 到 5 倍（ Intel VC6 STL/CRT ）。 .NET 环境下字符串是内部处理的，这表示字符串存储在全局离散表中，副本可以从内存中消除，等值测试是以一致性检查的方式进行的 ( 只要两个参数都是在内部 ) 。这明显表示内部修复机制的效率严重低下或者一致性检查没有建立 C# 的 ”string-swatching” 机制性。 C# 的这种严重低效率更让人倾向于后者，因为想不到个好的理由解释为什么会这样。正如例 8 所示，变量 1 的字符串实例是文字的，都在内部（事实上，这里有个限制没有在例 8 中表示出来，在变量 1 的预循环中用来验证参数是真正在内部的）。

当在变量 2 中假装进行一致性检查，发现仅 Java 的性能有明显的提高，从 2% 到令人印象深刻的 30% 。很明显 Java 在使用一致性检查所取的性能是不切实际的，因为在真正的程序中不能限制字符串都是文字的。但这可用来说明支持内部处理和提供可编程实现访问这种机制的语言的一种性能。讽刺的是， C# 作为这五种语言之一，它的性能是最差的。

Strcat : 表 2 以微秒（ μs ）显示了五种语言每一种在这个例子中的四个变量的花费时间。本文没有足够的篇幅来细节描述 17 执行代码，但尽量保持例子 7 的四个变量的真实面貌。变量 1 和 2 在所有语言执行代码中涉及以堆栈为基础的字符串内存，同时 C ， D 语言在第三个变量中、 C ， C++ ， D 语言在第四个变量中用结构内存，这在某种程度说明他们的性能优于其他变量和语言的执行代码。本例子的 C ， C++ 的讨论适合于 Digital Mars 版本，因为很明显的 Intel 所带来的性能提高被 Visual C++ 运行时刻库的效率（非期望）所抵消，事实上 Intel 的每种测试的性能都比 Digital Mars 的差。

第一种测试是以默认的方式执行的，很显然 C# 和 D 语言的性能都好于其它语言。很奇怪的是 Java 的性能最差，因为 Java 被认为有能力在一条语句中把字符串序列解释成字符串构件格式（在变量 4 中手工转换）。

第二种测试，众所周知它的格式不好，透露了很多东西。它的劣性根据语言而不同，对于 C# ， D 和 Java ，包含在连续的表达式中连接每一项，而不是象第一个变量在一个表达式中。对于 C ，它简单地省略了在开始多项连接重新分配之前的的内存请求。对于 C++ ，它使用 strstream 和插入操作符而不是使用 str::string 和 + （）操作符。结果显示所有语言不同程度地降低性能。 C 内存分配器的附加轮询看起来没有起多大作用，可能因为没有竞争线程造成内存碎片，所以消耗同样的内存块。 C++ 改变成 iostreams 使代码更紧凑，但没有转变数字部分，它们仅被插入到流当中，所预计的执行结果验证了这一点。 D 因为这个改变降低性能许多（ 32% ）， Java 更多（ 60% ）。很奇怪的是 C# 性能在这里仅降低很小，少于 7% 。这让人印象非常深刻，意味着可能在 .NET 的开发环境下因为 Java 字符串连接而形成的代码回查的警觉本能会衰退。

第三种测试使用 printf()/Format() 的变量不足为奇。通过使用部分 / 全部的帧内存， C ， C++ 和 D 达到很好的性能。奇怪的是 C# 的性能仅是 22% ，简直不值一提。 Java 根本没有这个便利功能。（以个人的观点也是不值一提的） C#和D语言都能够在封闭的循环中，依照数组边界测试情况，优化他们的越界检查。

最大的 测试 －硬编码的性能－这个是很有趣的问题，因为 C++还是能提供超级的性能，如果能够依照问题的精确领域来编码，即使别的语言（C#,java）使用默认的或者性能优化的组件或者理念也是如此。在C#和java上使用他们各自的StringBuilders能够提供真实的效果，达到他们在这个集合中的最佳性能。然而，C#能发挥最佳效率的机制，还是不能与C/C++、D语言相比。更糟糕的是，java的最佳性能都比别的语言的最差性能要可怜，这是相当可悲的。

总之，我们说对底层直接操作的语言垂手可得地赢得那些转化率工作得很好的或者完全地在中间代码中，并且很显然地能够提供良好性能的语言用法对java是很重要的而对C#是不太重要的。请注意这一点。

Strtok . Table3显示了五种语言的每一个环节总共的时间（单位是毫秒ms）。同时他们的空间占用在这篇文章中并没有提及，但是所有语言的实现都是非常直接的并且很明显很接近在Listing9中列出的四个问题的本质。与strcat一样，基于同样的原因，使用Intel编译器的结果没有讨论。

第一个问题――分割字符，保留空格――显示C++版本是明显的胜利者，D语言要慢20％，C# 要3倍的时间。显然，这个与库的特征的关系比语言的更明显，

并且我使用 tokenizer比著名的Boost更多一些，那样的话，D语言要比C++快2倍，并且C＃只慢20％。虽然如此，STLSoft的tokenizer是免费得到,我想我们应该把这个作为C++的一个胜利。（其实，template在这一点上的使用STL的basic_string作为他的值类型，这个并不因为他的良好性能而闻名，这可能引起争论－我并没有使用一个更有效率的string，就像STLSoft的frame_string.总之，我认为这是个公平比较）。

第二个问题－－分割字符，去掉空格－－包含所有语言的实现版本。自然地，C语言赢得了比赛，它使用了strtok()函数，这个函数在创建tokens时并不分配内存并且直接写终结符NULL到tokenized string的结尾。尽管有这些不利条件，C++的性能还是很好的，时间是C的221％，比较好的是D语言，432％。

C＃和java就很差了，分别是746％和957％。这简直是不敢相信的，C＃和java运行的时间是C++的3.4倍和4.3倍，这三种语言都为tokens分配了内存。我相信这个是STL模型在处理iterable sequences时比passing around arrays更有效率的很好的例子。（请注意，我们有高度的信心这是场公平的关于C++,C#和D语言的比较，我写了三种tokerizer的实现，都是公开的，可得到的.)

第三个问题－－分割句子，保留空格--显示了两件事情。第一，在这三种语言在实现这个程序的代价比实现单个字符更昂贵。第二，我们发现D语言取代了C++的最佳性能的地位，领先5％左右。C＃继续被甩下，大概是另外两种语言的1.8倍时间左右。

第四个问题－－分割句子，去掉空格--没有任何令人意外的，C++和D拥有大概一致的性能。C＃比较不错（大概2倍的性能差距）java更慢（差不多3倍时间）。对于C++，C＃和D来说去掉空格比不去掉空格导致一小点的性能损失。很明显的，在C＃中，这么做比其他两个的损失更大一点。很有价值的是，这些功能在C＃和D中是已经实现的。由于数组在C#中是不可变的，从tokens中返回一个没有空格的数组将导致重新分配一个数组。可是，D允许指派数组的长度，这个能动态地调整数组的大小这是个很好的例子说明D语言提供更好的效率。

总的来说，考虑到性能和自由度，我们能够说 C++是胜利者，D是很接近的第二名。C拥有最佳的性能，但是只支持一种类型的tokerization。C＃表现得很差，java更甚。

总结

我们可以把结果分成3种情况：这些包括语言的特性，包括库的特性，或者两者都相关。这些只与语言相关的特性显示在 f2i, i2f, picalc, picalcr, and sieve scenarios,这些在语言选择上的作用是很小的。c＃看起来在总体上是最好的，但是有点让人不能信服的是它在f2i中取得的优异性能并且是因为牺牲了浮点精确度而取得效率。（这一点需要更多大检查，我将在下一篇文章中去做。）

java是明显最差的 。

当讨论intel编译器的浮点计算的深度优化效果时，它很明显地显示，c和c++能够做的比C＃更好。我讨论这些并不是说这些语言必须要更好的效率，而是说他们能比其他的语言提供更好的优化和增强的机会。这个大概是与本主题完全不相干的是，C和C++比别的语言有更多的编译器；更多的竞争，更聪明的人拥有不同的策略和技术。编译器的结果的运行目标是处理器，这将导致戏剧性的效果；我们仅仅在表面上探讨了这个庞大的问题，但是我不久将在以后的文章中回到这个主题。

Strtok 是唯一一个能说是library-only的，在这一点上C＃干的并不好。虽然比java快，但是比其他的语言慢2倍或更多。同样令人失望的是VisualC/C++的运行库。在这一点上包括语言和库的效果的是i2str,str2i,strcat和strtswtch，描绘的并不是很清楚。C＃明显的在string的拼接这一环节上比java好得多，但是明显地比其他的差。关于尊敬的C，C++,D，只是在一些环节上领先，在另外一些环节上相当地差。

很有趣的是定制的C++的库替换加上深度优化的intel的编译器。

总之，不可能做出定量的结论。从语言的表层来看， C# 和 Java 挺简单的，但低效的库降低了速度。我觉得，当相关的库还不如语言本身的时候， C# 的确实有微弱的优势；但反过来，当库逐渐完善，超过语言本身后， C# 明显就不行了。但还是能看到一点点希望： C# 还是有可能实现预期的目标，因为库比语言更容易实现组装。但是，人们认为由于跟别的语言相比， C# 和 Java 所用的库与语言结合的更加紧密，这些库就可以作为这两种语言效率的关键所在，至少对当前的版本来说是这样的。

正如我所作出的示范（从整数到字符）以及相关提到的（从字符到整数），有人可能会批评者并不符合这篇文章的原意。

更深入的探讨

本文主要探讨了一下 C# 对 C++ 和 Java 可能造成的“威胁”。总的来说，这结果虽然不怎么鼓舞人心，却足以让人吃惊。从效率上看， C# 跟 C 以及 C++ 这些过去的同类产品（假如它们是更高效的）相比只能算是一般水平，至少在基本语言特征的比较上是这样的。从某种程度上来说， Java 也是如此。（我承认我无法证明 C 和 C++ 相对于 C# 的绝对优势。在多年前我的毕业论文分析调查期间，我认识到令人乏味的结果正和令人兴奋的结果一样生动形象，但前者花费更小的经济支出。）

上述结论对于多处理器以及（高性能的文件／网络处理系统）等来说却不一定适用。不过，这确实很好地展现出了这些语言的基本效率以及更复杂的运算所依赖的最基本的库。

就 D 发展状况来看，现在就对它进行这样的归类似乎为时过早，不过它现在的表现确实不错。 D 的效率至少是 C# 的 167% ，其实大多数情况下还不止。有些人指出，目前仅仅还处于字符时代，只需几个人就能完成一个编译器及其附带的库。我猜测， D 有可能发展成一门强大的技术。

就我个人而言，作为一个对 C# 持有偏见的人，偶然还是会对它的性能感到惊讶。我热切地期盼着能将性能的对比分析延伸到更多领域：复杂而高效的内存的应用，多线程，进程通信，特殊文件处理，手写代码开销，这些技术都能让我们对语言进行更深入的研究。能看到 Inter 公司怎样通过定制的 C Library （比如 CRunTiny ；参考 http://cruntiny.org/ ）和 STL （比如 STLPort ）。

鸣谢

感谢 Walter Bright 为我提供了一份言简意赅的关于 D 的介绍，并及时地指出了一些当时被我忽略的优点，使我能对测试工程进行改进。同时也要感谢 Sun Microsystems 公司的 Gary Pennington ，他为我提供了关于 Java 方面的资料。还有 Scott Patterson ，他对本文的草稿进行了大量的精简，并对全篇文章进行了细致的检查。