素材均来自网络，请遵守各相关软件的协议。本文转帖请注明作者或出处。

环境

WinXP sp2、VC6 + VisualAssist X、SlickEdit 12、doxygen + graphviz

下载

CppUnit 1.12.1 下载 744.92KB

编译

解压缩

解压缩下载到的cppunit-1.12.1.tar.gz文件得到一个名为cppunit-1.12.1的文件夹，其下有（关键文件和目录）：

• [examples]
• [include]
• [lib]
• INSTALL
• INSTALL-WIN32.txt
• README

记此目录 X:\the\path\cppunit-1.12.1 为 <U> 。

环境配置

如确定 VC6 已经有 unicode 库支持。此步可跳过。

进入控制面板→添加/删除程序，配置 VC 安装组件。检查 VC 中 unicode 是否支持。

如果没有安装 unicode 支持，若安装盘在，可以插入光盘，再此选中并一路确定，将之安装上即可。

若安装盘不在，可下载此文件后，将其中的 lib 文件放到 VC 安装目录下的 VC98\MFC\LIB 目录。

编译库文件

打开 <U>\src\CppUnitLibraries.dsw 。Build→Batch Build→全部选中后Build。

打开 <U>\examples\examples.dsw 。同上，全部Build。

安装

给VC6中注册插件

Tools
→ Customize
→ Add-ins and macro files
→ Browse
→ 选择或输入 <U>\lib\TestRunnerDSPlugIn.dll
→ 确定

VC6

Tools
→ Options
→ Directories
→ Show directories for:

• Include files 中，添加 <U>\include
• Library files 中，添加 <U>\lib
• Executable files 中，添加 <U>\lib

VisualAssist X

Visual Assist X Options
→ Project
→ C/C++ Directories
→ Platform: Custom
→ Show Directories: Stable include files
→ 添加 <U>\include

SlickEdit12

Tools
→ Tag Files
→ "C/C++" Tag Files
→ Add Tag File
→ C/C++
→ 选中Generate References
→ OK
→ 输入名称：CppUnit.vtg
→ 打开
→ 选择路径 <U>\include
→ OK
→ Done

使用

测试使用例子：CppUnit测试框架入门

一个简单的构造过程：编写GUI类型的CppUnit单元测试框架及用例

基本框架推荐模型：CppUnit 快速使用指南

几年来，第一次做梦这么清楚，醒来后，竟然大体的脉络全都能记下来。

两个朋友带我与一个女业余车手赛车。跑道是某体育场的跑道，地面是土路，跑道上有不少其他人在锻炼，跑的过程中需要躲人。赛程是三圈。我开的是奥拓，车型完全就是现实中一个朋友的二手车。对方开的我不认识。

我完全不会开车，在吹哨出发前，我把油门当作刹车踩了一下，于是我就在前头“抢跑”了。游戏继续。为表示公平或是什么原因，我一直试图刹车，直到吹哨出发，对方超过我，才继续踩油门。

跑的过程中，不懂换档，自己摸索，各种控制设备的位置感觉和现实中另一个朋友的欧兰德完全一样。听不出转速，一通瞎换。好在，还知道换的时候需要踩离合。开始有几次换档没换到位，导致车的感觉怪怪的。速度也没加上。被落后很远。跑着，躲避行人。跑到两圈半的时候，不知道是什么原因车走不了了，只好就停在跑道上，下车步行向终点。

我抛锚的时候，对手已经过了终点，不知为何，她又多跑了一圈，路过我的位置，依稀可见其愤愤的表情。估计大概是“怎么和这么水的对手跑了，丢人”之类的原因吧。

回到终点后，我带着一个朋友继续走，去抛锚的车那里。奇怪的是，我们都是沿着跑道走，全没有从中间穿越的想法。到了车那里，朋友简单看了一下，就让我上车，带我返回终点。不知为何，跑道拐弯处旁边不远有个土堆，也许是修什么东西挖出来的，在这个位置超越旁边的行人时，无奈停了一下，避让。再前进刚起动一两米，朋友看见了车外的另一个朋友，停车下去与其聊天。过一会才继续上车载我到终点。

到了终点。我醒了。

复杂的梦。这么多的元素。乱乱的感觉倒是我一贯梦境的风格。

一、接触问题

事情[1]起源于，有人写了这样的代码：

divisors i = [j | j<-[1..i-1], i `mod` j == 0]
main = print [i | i<-[1..10000], i == sum (divisors i)]

然后用 C 写了相同逻辑的嵌套循环。

运行的时候发现，Haskell 程序运行的时间是 C 程序运行时间的接近 14 倍。为何如此呢？

问题提出以后，有人简单地给他补充了这样一句：

divisors :: Int -> [Int]

再次运行时发现，Haskell 程序运行的时间仅为 C 程序运行时间的 1.6 倍。

二、分析问题

是什么导致了程序的行为有如此大的差异呢？

查找资料后发现，Haskell 的默认数值类型是 Integer 。在函数声明缺省的状态下，对 divisors 函数的编译、优化也是基于此类型的。而众所周知的，较之于 Int ，Integer 有更大的数值范围。相对地，牺牲的就是性能。

这样看起来，有了这个声明，编译器就可以大胆地进行优化了。[2]

三、走远一点[3]

优化以后，为何还有 1.6 倍这个区别呢？

在计算机世界的原始社会中，就有这样一句话流传着：程序=数据结构+算法。

且不论这句话到现在是否已经过了保质期。起码我们可以由此知道，在相同算法的前提下，要比较效率，还需要保证所使用的数据结构是相同的。

Haskell 的世界里，list 是通过链表实现的（这也就是它支持无穷数列的原理基础）。所以，要比较 C 与 Haskell 的性能优劣，也许把 C 实现的数据结构改成使用链表更为平等些。

除了算法和数据结构，程序中包含了用于显示部分的代码。要比较性能，最好把显示部分剥离出来分别比较。

四、深入一步

除了 Integer 与 Int 以外， Haskell 中还有 Int16、Int32、Int64 等类型。

对于本文开头的问题，且不讨论范围更小的 Int16 ... 。不失一般性，也暂不分析无符号的类型 UInt32 。就简单比较一下，Int - Integer - Int32 - Int64 的性能优劣。

具体的分析步骤就不一一列举了(参见[1])。这里只陈述一下在 32 位平台下，简单优化后的分析结果。

效率比 Int : Int32 : Integer : Int64 ≈ 1 : 1 : 7.5 : 9

所以，在需求允许的情况下，尽量只用 Int 类型，如果数值范围较大，简单地使用 Integer 类型就够了。

[1] 事件的完整记录在这里。
[2] 在声明对编译器行为的重要性这一点上，Haskell 编译器与其他语言的编译器并无二致，在写、进而优化代码的时候，一定要仔细斟酌。
[3] 这里的走远，仅仅是承认了 Haskell 本身与 C 在实现上有一定的区别，并无其他含义。

[Levi]原文亦是转贴且无出处，so...

当你的手机电池使用时间变短(记忆效应或老化)时 , 你是否会再买一颗电池来更换呢?

下次当你碰到这种情况时请省下你的钱 , 告诉你一个很有效的方法不妨试试看:

1.用橡皮把电池的金属触点上的污物搽掉，试试使用时间是否延长。

2. 把电池用报纸包起来再放进塑胶袋里包好放入冰箱三天(报纸可吸收多余水份)

3. 三天后取出常温下放二天

4. 二天后将电池充电 , 充足后装进手机里测试 (预计可救回80%-90%)

此方法也同样适用于其他数码产品俚电电池。如数码相机，数码摄象机，mp3，mp4等等。
至于有没有效果,反正电池快没用了,而且冰箱人人有,各位朋友不妨试试看吧 !

[Levi]本人未验证，不过有空可以尝试一下。