类

类的概念在许多语言中出现，很容易理解。它将数据和操作进行封装，以便将来的复用。

模块

模块，在Python可理解为对应于一个文件。在创建了一个脚本文件后，定义了某些函数和变量。你在其他需要这些功能的文件中，导入这模块，就可重用这些函数和变量。一般用module_name.fun_name，和module_name.var_name进行使用。这样的语义用法使模块看起来很像类或者名字空间，可将module_name 理解为名字限定符。模块名就是文件名去掉.py后缀。下面演示了一个简单的例子：

#moduel1.py
def say(word):
    print word

#caller.py
import module1

print __name__
print module1.__name__
module1.say('hello')

$ python caller.py
__main__
module1
hello

例子中演示了从文件中调用模块的方法。这里还展示了一个有趣的模块属性__name__，它的值由Python解释器设定。如果脚本文件是作为主程序调用，其值就设为__main__，如果是作为模块被其他文件导入，它的值就是其文件名。这个属性非常有用，常可用来进行模块内置测试使用，你会经常在一些地方看到类似于下面的写法，这些语句只在作为主程序调用时才被执行。

if __name__ == '__main__':
    app = wxapp(0)
    app.MainLoop()

模块搜索路径

上面的例子中，当module1被导入后，python解释器就在当前目录下寻找module1.py的文件，然后再从环境变量PYTHONPATH寻找，如果这环境变量没有设定，也不要紧，解释器还会在安装预先设定的的一些目录寻找。这就是在导入下面这些标准模块，一切美好事情能发生的原因。

import os
import sys
import threading
...

这些搜索目录可在运行时动态改变，比如将module1.py不放在当前目录，而放在一个冷僻的角落里。这里你就需要通过某种途径，如sys.path，来告知Python了。sys.path返回的是模块搜索列表，通过前后的输出对比和代码，应能理悟到如何增加新路径的方法了吧。非常简单，就是使用list的append()或insert()增加新的目录。

#module2.py
import sys
import os

print sys.path
workpath = os.path.dirname(os.path.abspath(sys.argv[0]))
sys.path.insert(0, os.path.join(workpath, 'modules'))
print sys.path

$ python module2.py
['e:\\Project\\Python', 'C:\\WINDOWS\\system32\\python25.zip', ...]
['e:\\Project\\Python\\modules', 'e:\\Project\\Python', 'C:\\WINDOWS\\system32\\python25.zip', ...]

其他的要点

模块能像包含函数定义一样，可包含一些可执行语句。这些可执行语句通常用来进行模块的初始化工作。这些语句只在模块第一次被导入时被执行。这非常重要，有些人以为这些语句会多次导入多次执行，其实不然。

模块在被导入执行时，python解释器为加快程序的启动速度，会在与模块文件同一目录下生成.pyc文件。我们知道python是解释性的脚本语言，而.pyc是经过编译后的字节码，这一工作会自动完成，而无需程序员手动执行。

包

在创建许许多多模块后，我们可能希望将某些功能相近的文件组织在同一文件夹下，这里就需要运用包的概念了。包对应于文件夹，使用包的方式跟模块也类似，唯一需要注意的是，当文件夹当作包使用时，文件夹需要包含__init__.py文件，主要是为了避免将文件夹名当作普通的字符串。__init__.py的内容可以为空，一般用来进行包的某些初始化工作或者设置__all__值，__all__是在from package-name import *这语句使用的，全部导出定义过的模块。

创建PO文件

PO文件是Portable Object文件的简称，它包含需要翻译的字符串。我们需要从源文件进行提取。首先，对源文件test.py编辑，标识代码里需要翻译的字符串内容。我们使用_("xx")的方法，这种形式可能在许多开源源代码中见识过。

#加载菜单栏
menubar = rc.LoadMenuBar('IDR_MENU')

这里的IDR_MENU是资源标识ID，不需要翻译，因此不做改变，而下面的代码：

info.SetVersion('1.0')
info.SetDescription('XRC i18n Demo')

'XRC i18n Demo'是描述性的文本，需要进行翻译，将需要处理为

info.SetVersion('1.0')
info.SetDescription(_('XRC i18n Demo'))

接着需要生成.pot(Portable Object Template)，这是po的模板文件。在将来程序可能配置成其他语种，其他语言的po文件都从它而来。为了创建这文件，需要用到GNU gettext工具集中的xgettext。向xgettext传入些必要的信息，来创建.pot文件。

>xgetttext --output=test.pot test.py

我们将wxPython界面以XRC文件保存了，那里同样有要翻译的字符串需要提取。用XRCed工具将XRC生成python代码，勾选上'Generate gettext strings'项即可。将源文件和XRC生成的test_xrc.py文件一起处理，生成一个test.pot。

>xgettext --output=test.pot test.py test_xrc.py

将得到的test.pot另存为test.po文件，然后进行翻译编辑，在这过程中文件需要使用utf-8编码。将对应的英文翻译成中文，将charset更改为utf-8。

"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"

#: test.py:19
msgid "XRC i18n Demo"
msgstr "XRC 国际化示例"
...

.pot和.po这些文件都是文本文件，主要供翻译者使用。为了使程序在运行时能获取相关的翻译的内容，要进行所谓的编译过程，将文本文件转换为二进制文件.mo。这里用了gettext工具集中的另一程序msgfmt。

> msgfmt --output=test.mo test.po

因为windows下没有像linux像有公共存储.mo文件的目录，保持平台的迁移性，在应用程序本地目录下新建locale目录，用来存放编译过的.mo文件，然后将test.mo移动至locale目录。在完成这些步骤后，就转入代码方面的更改了。

wxPython代码更改

原先的代码只需要做小改动：

def OnInit(self):
    wx.Locale.AddCatalogLookupPathPrefix('locale')
    self.locale = wx.Locale(wx.LANGUAGE_CHINESE_SIMPLIFIED)
    self.locale.AddCatalog('test')
    import __builtin__
    __builtin__.__dict__['_'] = wx.GetTranslation

首先，增加了新的目录文件路径，这将使wxPython搜索这个目录，寻找匹配的.mo文件。接着创建wx.Locale对象，将其初始化为简体中文，这将对应于zh_CN。最后将wx.GetTranslation做了一全局映射，这样你在其他类中，比如示例中TestFrame也能使用_('xx')调用。这样wxPython的i18n工作就完成了，下面是翻译前后的界面截图。

一些有益的讨论

.mo文件的查找目录

如果你将locale目录下的test.mo文件删除掉，然后将test.py中的wx.LANGUAGE_CHINESE_SIMPLIFIED改为wx.LANGUAGE_CHINESE，重新运行程序看看。发现界面变成了如下的繁体中文，但是菜单'档案'下的Exit还是英文。

因为缺失.mo文件，但又指定wx.LANGUAGE_CHINESE，wxPython运行时使用了wxstd.mo文件。wxstd.mo有许多预编译好的常见字符串的对应关系，它随wxPython发布，在wx/locale下有许多语言版本的wxstd.mo。

对于wxPython会对待查目录"DIR"来搜索.mo文件，查找它下面的这些目录,(DIR/LANG/LC_MESSAGES;DIR/LANG;DIR),对于哪些是待查目录，各个系统下又有不同，在所有的平台上,LC_PATH环境变量指定的目录将成为待查目录，在Linux下/share/locale, /usr/share/locale, /usr/lib/locale, /usr/locale /share/locale以及当前目录将是待查目录。在上面我们已经用过AddCatalogLookupPathPrefix()函数，其作用就是增加自己的待查目录。

在示例程序中，将test.mo放在locale\zh_CN\LC_MESSAGES或者locale\zh\LC_MESSAGES同样是可行的。但是如果使用wx.LANGUAGE_CHINESE指定，则zh_CN目录将不可行，因为它只是特化目录，指简体中文，而zh目录同样适用。

工具链再讨论

gettext进行国际化是开源社区的主流方案，它也提供了许多实用工具供使用。上面提到了xgettext,msgfmt，还有msginit.exe，它将根据.pot文件创建新的.po文件，然后初始化一些元信息，像作者信息，项目，以及编码等，当然也可像上面的手工编辑。msgmerge.exe将两个.po文件进行合并。除了使用GNU Gettext工具集，也可使用随python发布的tool\i18n目录下pygettext.py和msgfmt.py，它们等同于上述的两个工具。

对于编辑.po文件，可以尝试一下Poedit,它提供了图形化的编辑环境，其他功能我就不清楚了。

但在找到这篇文章之前，和编写插件的过程中，还是费了很多功夫。最早我认为写插件是需要下载SDK之类的软件，所以在Live Writer官方开发网站，Live Writer网，MSDN之类的找了个遍，看见是有SDK之类字样的下载，但弄不下来只有文档，根本不见其什么头文件，DLL之类的。在这花费了很多时间，最后才发现WLW插件的SDK是随WLW一起分发了，也就是WindowsLive.Writer.Api.dll之类的，这些dll 都随WLW主程序在一个目录中。还有一点是，现在WLW在中国是随Live套件一起发布的，因此路径由原来的C:\Program Files\Windows Live Writer变成了C:\Program Files\Windows Live\Writer，插件目录为Plugin。如果在网上发现有好用的插件，只需要将其发布的插件dll扔到这个目录就行了。

在开发中碰到图标资源不能成功加载，在Dflying Chen的文章中特意提到了图标资源需要是嵌入形式，我也按照其操作的，总以为是这里出现问题。后来花了一些时间，才找到总是的根源：自己在开发中更改了工程名，导致最后生成的程序集的名称与后来的命名空间名称不一致，图标路径就出错了。C#也只是这次用一下，这些都没有接触到。

昨天弄完自己的“插入Pre标记”插件后，想到自己写博客常需要截图，遂想再开发一个截图工具的。最早搜到了别人调用SnagIt搜件，不好用，因为SnagIt是商业软件，需要注册的。后来找到了picpick，小巧免费，非常实用。我想调用picpick的，但是在参照Insert SnagIt Screen Capture发现是用COM接口，而无奈picpick没有这样供开发使用的接口考虑，最终不可行。后来经过一些其他的尝试，都告失败。最后还是搜索帮了忙，找到了Screen Capture这个插件，原来有别人已完工了。

最后附上，我用这个新插件截的图，非常好用，只需一步：

一旦线程对象被创建，它的活动需要通过调用线程的start()方法来启动。这方法再调用控制线程中的run方法。

一旦线程被激活，则这线程被认为是'alive'(活动)。当它的run()方法终止时-正常退出或抛出未处理的异常，则活动状态停止。isAlive()方法测试线程是否是活动的。

一个线程能调用别的线程的join()方法。这将阻塞调用线程，直到拥有join()方法的线程的调用终止。

线程有名字。名字能传给构造函数，通过setName()方法设置，用getName()方法获取。

线程能被标识为'daemon thread'(守护线程).这标志的特点是当剩下的全是守护线程时，则Python程序退出。它的初始值继承于创建线程。这标志用setDaemon()方法设置，用isDaemon()获取。

存在'main thread'(主线程),它对应于Python程序的初始控制线程。它不是后台线程。

有可能存在'dummy thread objects'(哑线程对象)被创建。这些线程对应于'alien threads'(外部线程),它们在Python的线程模型之外被启动，像直接从C语言代码中启动。哑线程对象只有有限的功能，它们总是被认为是活动的，守护线程，不能使用join()方法。它们从不能被删除，既然它无法监测到外部线程的中止。

class Thread(group=None, target=None, name=None, args=(), kwargs={})

构造函数能带有关键字参数被调用。这些参数是:

group 应当为 None，为将来实现ThreadGroup类的扩展而保留。

target 是被 run()方法调用的回调对象. 默认应为None, 意味着没有对象被调用。

name 为线程名字。默认，形式为'Thread-N'的唯一的名字被创建，其中N 是比较小的十进制数。

args是目标调用参数的tuple，默认为()。

kwargs是目标调用的参数的关键字dictionary，默认为{}。

如果子线程重写了构造函数，它应保证调用基类的构造函数(Thread.__init__())，在线程中进行其他工作之前。

start()

启动线程活动。

在每个线程对象中最多被调用一次。它安排对象的run() 被调用在一单独的控制线程中。

run()

用以表示线程活动的方法。

你可能在子类重写这方法。标准的 run()方法调用作为target传递给对象构造函数的回调对象。如果存在参数，一系列关键字参数从args和kwargs参数相应地起作用。

join([timeout])

等待至线程中止。这阻塞调用线程直至线程的join() 方法被调用中止-正常退出或者抛出未处理的异常-或者是可选的超时发生。

当timeout参数未被设置或者不是None,它应当是浮点数指明以秒计的操作超时值。因为join()总是返回None，你必须调用isAlive()来判别超时是否发生。

当timeout 参数没有被指定或者是None时，操作将被阻塞直至线程中止。

线程能被join()许多次。

线程不能调用自身的join()，因为这将会引起死锁。

在线程启动之前尝试调用join()会发生错误。

getName()

返回线程名。

setName(name)

设置线程名。

这名字是只用来进行标识目的的字符串。它没有其他作用。多个线程可以取同一名字。最初的名字通过构造函数设置。

isAlive()

返回线程是否活动的。

大致上，线程从 start()调用开始那点至它的run()方法中止返回时，都被认为是活动的。模块函数enumerate()返回活动线程的列表。

isDaemon()

返回线程的守护线程标志。

setDaemon(daemonic)

设置守护线程标志为布尔值daemonic。它必须在start()调用之前被调用。

初始值继承至创建线程。

当没有活动的非守护线程时，整个Python程序退出。

参见:Python Library Reference

命令行接口是普遍,基础的人机交互接口，从命令行提取程序的运行时选项的方法有很多。你可以自己编写相对应的完整的解析函数，或许你有丰富的C语言编程经验，熟知getopt()函数的用法，又或许使用Python的你已经在使用optparse库来简化这一工作。大家在平时不断地谈及到“不要重复造轮子”，那就需要掌握一些顺手的库，这里介绍一种C++方式来解析命令行选项的方法，就是使用Boost.Program_options库。

program_options提供程序员一种方便的命令行和配置文件进行程序选项设置的方法。使用program_options库而不是你自己动手写相关的解析代码，因为它更简单，声明程序选项的语法简洁，并且库自身也非常小。将选项值转换为适合的类型值的工作也都能自动完成。库有着完备的错误检查机制，如果自己手写解析代码时，就可能会错过对一些出错情况的检查了。最后，选项值不仅能从命令行获取，也能从配置文件，甚至于环境变量中提取，而这些选择不会增加明显的工作量。

示例说明

以下面简单的hello程序进行说明，默认打印hello world,如果传入-p选项，就会打印出人的姓名，另外通过传入-h选项，可以打印出帮助选项。略微看一眼代码文件和相应的屏幕输入输出，然后我们再一起来看看这些是如何发生的。

//hello.cpp 
#include <iostream>
#include <string>
#include <boost/program_options.hpp>

using namespace std;
int main(int argc, char* argv[])
{
    using namespace boost::program_options;
    //声明需要的选项
    options_description desc("Allowed options");
    desc.add_options()
        ("help,h", "produce help message")
        ("person,p", value<string>()->default_value("world"), "who")
        ;

    variables_map vm;        
    store(parse_command_line(argc, argv, desc), vm);
    notify(vm);    

    if (vm.count("help")) {
        cout << desc;
        return 0;
    }
    cout << "Hello " << vm["person"].as<string>() << endl;
    return 0;
}

下面是在Windows命令提示符窗口上的输入输出结果，其中">"表示提示符。

>hello 
Hello world

>hello -h
Allowed options:
  -h [ --help ]                produce help message
  -p [ --person ] arg (=world) who

>hello --person len
Hello len

首先通过options_description类声明了需要的选项，add_options返回了定义了operator()的特殊的代理对象。这个调用看起来有点奇怪，其参数依次为选项名，选项值，以及选项的描述。注意到示例中的选项名为"help,h"，是因为声明了具有短选项名和长选项名的选项，这跟gnu程序的命令行具有一致性。当然你可以省略短选项名，但是这样就不能用命令选项简写了。第二个选项的声明，定义了选项值为string类型，其默认值为world.

接下来,声明了variables_map类的对象，它主要用来存储选项值，并且能储存任意类型的值。然后，store,parse_command_line和notify函数使vm能存储在命令行中发现的选项。

最后我们就自由地使用这些选项了，variables_map类的使用就像使用std::map一样，除了它必须用as方法去获取值。如果as方法调用的指定类型与实际存储的类型不同，就会有异常抛出。

具有编程的你可能有这样的经验，使用cl或gcc对源文件进行编译时，可直接将源文件名放置在命令行中，而无需什么选项字母，如gcc a.c之类的。prgram_options也能处理这种情况，在库中被称为"positional options"(位置选项),但这需要程序员的一点儿帮助才能完成。看下面的经过对应修改的代码，我们无需传入"-p"选项，就能可指定"person"选项值

    positional_options_description p;
    p.add("person", -1);
    store(command_line_parser(argc, argv).options(desc).positional(p).run(), vm);

>hello len
Hello len

前面新增的两行是为了说明所有的位置选项都应被解释成"person"选项，这里还采用了command_line_parser类来解析命令行，而不是用parse_command_line函数。后者只是对前者类的简单封装，但是现在我们需要传入一些额外的信息，所以要使用类本身。

选项复合来源

一般来说，在命令行上指定所有选项，对用户来说是非常烦人的。如果有些选项要应用于每次运行，那该怎么办呢。我们当然希望能创建出带有些常用设置的选项文件，跟命令行一起应用于程序中。当然这一切需要将命令行与配置文件中的值结合起来。比如，在命令行中指定的某些选项值应该能覆盖配置文件中的对应值，或者将这些值组合起来。

下面的代码段将选项通过文件读取，这文件是文本格式，可用"#"表示注释，格式如命令行中的参数一样，选项=值

    ifstream ifs("config.cfg");
    store(parse_config_file(ifs,config),vm);
    notify(vm);

参考

Boost.prgram_options库文档

Boost Lambda库是C++模板库,以C++语言实现了lambda抽象.Lambda这个术语来自函数编程语言和lambda闭包理论,lambda抽象实际上定义了匿名函数.了解过C#新引入的匿数函数特性或Lisp编程的人，对这些概念理解会有很大帮助.Lambda库设计的主要动机是为STL算法提供灵活方便的定义匿名函数对象的机制.这个Lambda库究竟是有什么用呢?代码胜千言!看下面将STL容器中的元素打印到标准输出上的代码.

for_each(a.begin(), a.end(), std::cout << _1 << ' ');

表达式std::cout << _1 << ' '定义了一元函数对象.变量_1是函数的形参,是实参的占位符.每次for_each的迭代中,函数带着实际的参数被调用,实际参数取代了占位符,然后函数体里的内容被执行.Lambda库的核心就是让你能像上面所展示的那样,在STL算法的调用点,定义小的匿名函数对象.

Lambda库的安装

Lambda库只由头文件组成,这就意味着你不需要进行任何编译,连接,生成二进制库的动作,只需要boost库头文件路径包含进你的工程中即可使用.

与现代的C++语言一样,在使用时你需要声明用到的名字空间,把下列的代码包含在你的源文件头:

using namespace boost::lambda;

Boost Lambda库的动机

在标准模板库STL成为标准C++的一部分后,典型的STL算法对容器中元素的操作大都是通过函数对象(function objects)完成的.这些函数作为实参传入STL算法.

template <class T> 
struct plus : public binary_function <T, T, T> {
  T operator()(const T& i, const T& j) const {
    return i + j; 
  }
};

基类binary_function<T, T, T>包含了参数和函数对象返回类型的类型定义,这样可使得函数对象可配接.

class plus_1 {
  int _i;
public:
  plus_1(const int& i) : _i(i) {}
  int operator()(const int& j) { return _i + j; }
};

上面的代码显性地创建了一个函数对象,将其参数加1.这样的功能可用plus模板与binder模板(bind1st来等效地实现.举例来说,下面的两行表达式创建了一个函数对象,当它被调用时,将返回1与调用参数的和.

plus_1(1)
bind1st(plus<int>(), 1)

plus<int>就是计算两个数之和的函数对象.bind1st使被调用的函数对象的第一个参数绑定到常量1.作为上面函数对象的使用示例,下面的代码就是将容器a中的元素加1后,输出到标准输出设备:

transform(a.begin(), a.end(), ostream_iterator<int>(cout),
          bind1st(plus<int>(), 1));

所有这些工具都有一个目标,就是为了能在STL算法的调用点有可能指定一个匿名的函数,换句说,就是能够使部分代码片断作为参数传给调用算法函数.但是,标准库在这方面只做了部分工作.上面的例子说明用标准库工具进行匿名函数的定义还是很麻烦的.复杂的函数调用表达式,适配器,函数组合符都使理解变得困难.另外,在运用标准库这些方法时还有明显的限束.比如,标准C++98中的binder只允许二元函数的一个参数被绑定,而没有对3参数,4参数的绑定.这种情况在TR1实施后,引进了通用的binder后可能改善,对于使用MSVC的程序员,有兴趣还可以查看下微软针对VS2008发布的TR1增强包.

但是不管怎样,Lambda库提供了针对这些问题比较优雅的解决方法:

• 对匿名函数以直观的语义进行创建,上面的例子可改写成:

  transform(a.begin(), a.end(), ostream_iterator<int>(cout), 
            1 + _1);
  

  更直观点:

  for_each(a.begin(), a.end(), cout << (1 + _1));
  

• 绝大部分对函数参数绑定的限制被去除,在实际C++代码中可以绑定任意的参数

• 分离的函数组合操作不再需要了,函数组合被隐性地支持.

Lambda表达式介绍

Lambda表达在函数式编程语言中很常见.在不同语言中,它们的语法有着很大不同,但是lambda表达式的基本形式是:

lambda x1...xn.e

lambda表达式定义了匿名函数,并由下列的元素组成

• 函数的参数:x₁...x_n
• 表达式e,以参数x₁...x_n的形式计算函数的值

一个简单的lambda表达式的例子是:

(lambda x y.x+y) 2 3 = 2 + 3 = 5 

在lambda表达式的C++版本中,表达式中x₁...x_n不需要,已预定义形式化的参数.在现在Boost.Lambda库中,存在三个这样的预定义的参数,叫做占位符:_1,_2,和_3.它们分别指代在lambda表达式中的第一,二,三个参数.比如,下面这样的lambda表达式:

lambda x y.x+y

C++定义的形式将会是这样:

_1 + _2

因此在C++中的lambda表达式没有语义上所谓的关键字.占位符作为运算符使用时就隐性地意味着运算符调用是个lambda表达式.但是只有在作为运算符调用才是这样.当Lambda表达式包含函数调用,控制结构,转换时就需要特殊的语法调用了.更为重要的是,作为函数调用是需封装成binder函数的形式.比如,下面这个lambda表达式:

lambda x y.foo(x,y)

不应写成foo(_1,_2),对应的C++结构应如下:

bind(foo, _1, _2)

对于这种表达式,更倾向于作为绑定表达式bind expressions

lambda表达式定义了C++的函数对象,因此,对于函数调用的形式跟其他的函数对象一样,比如:(_1 + _2)(i, j).

性能

性能,运行效率,总是C++程序员关心的话题.理论上,相对于手写循环代码,使用STL算法和Lambda函数对象的所有运行开销,可以通过编译优化消除掉.这种优化取决于编译器,实际中的编译器大都能做到.测试表明,性能会有下降,但是影响不大,对于代码的效率和简洁之间的权衡,只能由程序员自己做出判断了.

Lambda库的设计与实现中大量运用了模板技术,造成对于同一模板需要大量的递归实例化．这一因素可能使构建复杂逻辑的lambda表达式，不是一个非常理想的做法．因为编译这些表达式需要大量的内存，从而使编译时间变得非常慢，这在一些大型项目中会更加突出．还有在发生编误错误时，引发的大量错误信息，不能有效地指出真正错误之处．最后点，C++标准建议模板的嵌套层次不要超过17层来防止导致无限递归,而复杂的Lambda表达式模板会很容易超过这一限制．虽然大多数编译器允许更深层次的模板嵌套，但是通常需要显性地传入一个命令行参数才能做到．

参考

大多数内容是从Boost.Lambday库在线文档参考翻译而成

http://doc.trolltech.com/qq/qq13-apis.html

翻译这篇文章的目的不是让人了解Qt，而是让人试着学习点C++编程的软技能。我从原文中得到的一些风格上的体会，也希望你能从中有所收获.（译者注)
我们在Trolltech做了大量研究来改进Qt开发体验.在这篇文章中,我将分享我们的一些成果,呈现我们在进行Qt 4设计时所使遵循的原现，并向你展示如何将它们应用到你的代码中．

• 优秀API的六个特性
• 方便性陷阱
• 布尔参数陷阱
• 静态多态
• 命名艺术
• 指针或引用?
• 案例分析:QProgressBar
• 怎样写出正确的API

设计应用程序接口(APIs)是有难度的.它是像跟设计编程语言一样困难的艺术．要遵循许多不同的的原则，这些原则中的许多还彼此冲突.

现今的计算机教育过多关注于算法和数据结构，很少去关注隐藏在程序设计语言和程序框架后面的那些设计原则．这使得程序员们面对日益重要的任务,创建可复用的组件,毫无准备.

在面向对象语言出现前,通用的可复用的代码大都由库提供者而不是应用程序开发者来编写.在Qt世界中，这种情况已发生了很大的变化．在用Qt编程其实就是在写新的组件.典型的Qt应用程序都存在某些自定义的组件，在整个应用程序中被复用.相同的组件常常作为其他程序的一部分被开发出来．KDE,K桌面环境,甚至使用许多附加库，来进一步扩展Qt，实现许多额外的类.

但是一个优秀,高效的C++ API究竟是怎样子呢?它的好坏取决于许多因素,比如说，手头上的任务和特定目标群体.优秀的API具有很多特性,它们的一些是普遍所要期望的,另一些是针对特定问题域的.

优秀API的六个特性

API对于程序员就相当于GUI对于最终用户.API中'P'代表程序员(Programmer)，而不是程序(Program)，强调这一点是为了说明API是让程序员使用的,程序员是人而不机器.

我们认为APIs应当精简而完备,具有清晰简单的语义，直观,易记且应使代码具有可读性.

• 精简性:精简的API具有尽可能少的类和公共成员.这使得理解，记忆，调试，更改API更加容易.
• 完备性：完备的API意味着拥有应具有的期望功能.这可能使与API保持精简性相冲突.还有，如果成员函数放在不相匹配的类中，那么许多使用这个功能函数的潜在用户会找不到它．
• 清晰简单的语义:正如与其他设计工作一样，你应该准守最小惊议原则.让通常的任务简单，罕见的任务应尽可能简单，但它不应成为重点.解决特定的问题．不要使解决方法具有普适作用，当它们不需要的时候.
• 直观性:与计算机有关的其他事情一样，API应具有直观性.不同经历和背景会导致对哪些是直观，哪些不是直观的不同看法．如果对非专业的用户在不需要阅读文档下能立即使用API,或对这个API不了解的程序员能理解使用了API的代码，那么这API就是具有直观性.
• 易记:为了使API容易记忆，使用一致且精准的命名规范.使用容易识别的模式和概念，避免使用缩写.
• 能生成可读生代码:代码只写一遍，却要阅读许多遍(调试或更改).可读性的代码有时候可能需要多敲些字,但是从产品生命周期中可节省很多时间.

最后，请记住：不同的用户使用API的不同部分.当简单地使用Qt类的实例可能有直观性，但这有可能使用户在阅读完有关文档后，才能尝试使用其中部分功能.

方便性陷阱

通常的误读是越少的代码越能使你达到编写更好的API这一目的.请记住，代码只写一遍，却要一遍又一遍地去理解阅读它.比如:

QSlider *slider = new QSlider(12, 18, 3, 13, Qt::Vertical,
                                  0, "volume");

可以会比下面的代码更难阅读(甚至于编写)

QSlider *slider = new QSlider(Qt::Vertical);
slider->setRange(12, 18);
slider->setPageStep(3);
slider->setValue(13);
slider->setObjectName("volume");

布尔参数陷阱

布尔参数常常导致难以阅读的代码.特别地，增加某个bool参数到现存的函数一般都会是个错误的决定．在Qt中，传统的例子是repaint(),它带有一个可选的布尔参数，来指定背景是否删除(默认是删除)．这就导致了代码会像这样子:

widget->repaint(false);

初学者可能会按字面义理解为,"不要重绘!"

自然的想法是bool参数节省了一个函数,因此减少了代码的臃肿.事实上,这增加了代码的臃肿，有多少Qt用户真正知道下面这三行代码在做什么呢？

widget->repaint();
widget->repaint(true);
widget->repaint(false);

好一点的API代码可能看起来像这样：

widget->repaint();
widget->repaintWithoutErasing();

在Qt 4中，我们解决这个问题的办法是，简单地去除掉不删除widget而进行重绘的可能性.Qt 4对双重缓冲的原生支持，会使这功能被废弃掉.

这里有些例子：

widget->setSizePolicy(QSizePolicy::Fixed,
                          QSizePolicy::Expanding, true);
textEdit->insert("Where's Waldo?", true, true, false);
QRegExp rx("moc_*.c??", false, true);

显然的解决办法就是将bool 参数用枚举类型来替换.这就是我们在Qt 4中Qstring中的大小写敏感所做的,比较下面两个例子:

str.replace("%USER%", user, false);               // Qt 3
str.replace("%USER%", user, Qt::CaseInsensitive); // Qt 4

静态多态

相似的类应该有相似的API.在某种程度上,这能用继承来实现,也就是运用运行时多态机制.但是多态也能发生在设计时.比如,你将QListBox与QComboBox交换,QSlider与QSpinBox交换,你会发现API的相似性会使这种替换变得比较容易.这就是我们所谓的"静态多态".

静态多态也能使记忆API和编程模式更加容易.因而,对一组相关类的相似API有时候比为每个类设计独特完美的API会更好.

命名艺术

命名有时候是设计API中最重要的事情了.某个类应叫什么名字,某个成员函数又应叫什么名字,都需要好好思考. 

通常的命名规则

有少许规则对所有类型的命名都适应.首先,正如我早先所提到的,不要用缩写．甚至对用"prev"代表"previous"这样明显的缩写也不会在长期中受益，因为用户必须记住哪些名字是缩写．

如果连API自身都不能保持统一,事情自然会变得更坏．比如，Qt 3中有activatePreviousWindow()函数，也有fetchPrev()函数.坚持"没有缩写"这条规则，会使创建一致的API更加简单．

在设计类中，另一重要但是不明显的规则是尽量保持子类中名字的简洁易懂．在Qt 3中，这个原则并不总是被遵守．为了说明这一点，我们举下QToolButton的例子.如果你在Qt 3中对QToolButton调用call name(), caption(), text(), 或 textLabel()成员函数时，你希望会发生什么?那就在Qt设计器中试试QToolButton吧．

• name 属性继承自QObject，用来在调试和测试中指代对象的内部名称．
• caption 属性继承自QWidget，指代窗体的标题．对于QToolButton没有什么意思，既然它们都是由父窗体创建的．
• text 属性继承自QButton，通常用于按钮中，除非useTextLabel为真．
• textLabel 属性 在QToolButton中声明，如果useTextLabel为真，则显示在按钮上．

为了可读性的关系，在Qt4中name 被称为objectName ,caption被称为windowTitle,在QToolButton中为了使text明晰，不再有textLabel属性.

命名类

不应为每个不同的类寻求完美的名字，而是将类进行分给．比如，在Qt 4中所有跟模型有关的视类的部件都用View后缀(QlistView,QTableView,QTreeView)，相应的基于部件的类用Widget后缀代替(QListWidget,QTableWidget,QTreeWidge).

枚举类型和值类型命名

当设计枚举时，我们应当记住C++中(不像Java或C#)，枚举值在使用时不带类型名.下面的例子说明了对枚举值取太一般化的名字的危害：

namespace Qt
{
    enum Corner { TopLeft, BottomRight, ... };
    enum CaseSensitivity { Insensitive, Sensitive };
    ...
};
    
    tabWidget->setCornerWidget(widget, Qt::TopLeft);
    str.indexOf("$(QTDIR)", Qt::Insensitive);

在上面这行中，Insensitive这个名字什么意思呢?为枚举类型命名具有指导的原则是最好在每个枚举值中重复枚举类型的名字．

namespace Qt
{
    enum Corner { TopLeftCorner, BottomRightCorner, ... };
    enum CaseSensitivity { CaseInsensitive,
                              CaseSensitive };
    ...
};
    
tabWidget->setCornerWidget(widget, Qt::TopLeftCorner);
str.indexOf("$(QTDIR)", Qt::CaseInsensitive);
    

但枚举值之间是一种"或"关系和被用作标志位时，传统的解决方法是将"或"结果存为int,这样做是类型不安全的.Qt 4提供了一模板类QFlags<T>，其中T是枚举类型.Qt为标志类型名称提供了便利，你能用Qt::Alignment 来代替QFlags<Qt::AlignmentFlag>.

为了方便,我们给枚举类型单数形式的名称(只有当只含一个标志位时)，给"flags"类型复数形式的名称，比如：

enum RectangleEdge { LeftEdge, RightEdge, ... };
typedef QFlags<RectangleEdge> RectangleEdges;
    

在某些情况下,"flags"类型有单数形式的名称.在这种情况下，枚举类型以Flag后缀标识:

enum AlignmentFlag { AlignLeft, AlignTop, ... };
typedef QFlags<AlignmentFlag> Alignment;

函数和参数的命名

函数命名中的一条规则就是应能从它的名字清楚地看出函数是否着副作用.在Qt 3中,常函数QString::simplifyWhiteSpace()就违反了这规则.即然它返回QString,而不是像它的名字所表述的那样修改字符串. 在Qt 4中,这个函数被重命名为QString::simplified().

参数名对于程序员来说是重要的信息来源,即使它们不出现在调用API的代码中.既然现代的IDE会在程序员编码时显示这些参数，所以非常值得在头文件中给这些参数取恰当的名字，在文档中同样使用相同的名字

给布尔型的getter,setter,属性的命名

给布尔型的getter,setter,属性取个恰当的名字总是特别困难．getter应该叫checked() 或者还是叫isChecked(),取scrollBarsEnabled()还是areScrollBarEnabled()

在Qt 4中，我们对于getter的函数使用下面的指导原则

• 形容词就使用is-前缀.比如:
  • isChecked()
  • isDown()
  • isEmpty()
  • isMovingEnabled()
  但是形容词应用到复数形式的名词没有前缀:
  • scrollBarsEnabled(), not areScrollBarsEnabled()
• 动词没有前缀，也不使用第三人称的(-s):
  • acceptDrops(), not acceptsDrops()
  • allColumnsShowFocus()
• 名词性的通常没有前缀:
  • 用autoCompletion(), 不用isAutoCompletion()
  • boundaryChecking()
  有时候没有前缀会产生误导，在这种情就加上前缀is-:
  • isOpenGLAvailable(), not openGL()
  • isDialog(), not dialog()
  (如果函数叫做dialog()，我们通常会认定它会返回QDialog*类型)

setter的命名可以从这推知，只要去掉is前缀，在名字前面加set前缀就可以了.比如setDown()和setScrollBarsEnabled().属性的名字跟getter一样，就是没有is前缀

指针或引用?

对于向外传参,是使用指针,还是引用更好呢?

void getHsv(int *h, int *s, int *v) const
void getHsv(int &h, int &s, int &v) const

绝大多数C++书籍都推荐无论何时都尽可能使用引用，因为从大多数情况来说，引用比指针有着所谓的"安全和优雅".相比而方，在Trolltech，我们更趋向于指针，因为它使用户代码更具可读性．比较下面的代码：

color.getHsv(&h, &s, &v);
color.getHsv(h, s, v);

只有第一行代码能更清楚地说明h,s,v在函数被调用后，其值极有可能被修改.

案例分析：QProgressBar

为了在实际代码中说明这些概念，我们以QProgressBar在Qt3和Qt4中的比较进行研究.在Qt 3中:

class QProgressBar : public QWidget
{
  ...
    public:
        int totalSteps() const;
        int progress() const;
    
        const QString &progressString() const;
        bool percentageVisible() const;
        void setPercentageVisible(bool);
    
        void setCenterIndicator(bool on);
        bool centerIndicator() const;
    
        void setIndicatorFollowsStyle(bool);
        bool indicatorFollowsStyle() const;
    
    public slots:
        void reset();
        virtual void setTotalSteps(int totalSteps);
        virtual void setProgress(int progress);
        void setProgress(int progress, int totalSteps);
    
    protected:
        virtual bool setIndicator(QString &progressStr,
                                  int progress,
                                  int totalSteps);
        ...
    };
    

对这个API进行改进的关键之处就是需要观察到Qt 4中QProgressBar与QAbstractSpinBox，以及它的子类,QSpinBox,QSlider,和QDial有着相似性.解决的办法呢?将其中的progress和totalSteps用minimun,maximum和value替换.

增加valueChanged()的信号量.增加setRange()这一方便的函数.

接下来需要到progressString, percentage 和indicator实际上都指代同一东西：显示在进度栏上的文本.通常这一文本是一百分数,但是它能被setIndicator()设置成任何值.这里是新的API:

virtual QString text() const;
void setTextVisible(bool visible);
bool isTextVisible() const;

默认，这文本是百分比指示器.这可以用重新实现的text()进行改变．

在Qt 3中，setCenterIndicator() 和 setIndicatorFollowsStyle()是两个影响对齐方式的函数.它们现在都被一个高级的函数所取代,setAlignment()．

void setAlignment(Qt::Alignment alignment);

如果程序员没有调用 setAlignment(),对齐是基于的样式决定的．对于Motif样式，文本显示在中间，而对于其他样式，文本是右对齐的．

这里是改进过的QProgressBar:

class QProgressBar : public QWidget32
{
        ...
    public:
        void setMinimum(int minimum);
        int minimum() const;
        void setMaximum(int maximum);
        int maximum() const;
        void setRange(int minimum, int maximum);
        int value() const;
    
        virtual QString text() const;
        void setTextVisible(bool visible);
        bool isTextVisible() const;
        Qt::Alignment alignment() const;
        void setAlignment(Qt::Alignment alignment);
    
    public slots:
        void reset();
        void setValue(int value);
    
    signals:
        void valueChanged(int value);
        ...
};

怎样写出正确的APIs

APIs需要质量保证．最早的版本一般都不是很好的，你必须测试它．通过调用这个API的代码作为测试事例，来验证代码具有可读性.

另外的技巧包括让人在没有文档和类文档化(类的概述和函数说明)的情况下能够使用这个API.

当你陷入麻烦中时，文档化也是好的办法找出一个合适的命名：试着为这些类，函数，枚举值标住文档，然后使用浮现在你脑中的第一个词汇.如果你找不到精准的名字去表述，那很有可能这个东西就不应存在．如果任何办法都失败了，而且你确信这个概念是有用的，那就发明一个新的名字吧．最后，不管怎么说,"widget", "event", "focus", and "buddy"这些词总会能用上一个.

在网上可以见到某些关于Glade的教程,大都是关于Linux平台和Glade 2的,因为原先Glade作为快速开发工具,集成代码生成功能,生成C文件.所以常常有初学者对网上某些教程所提及的"generate"(生成代码)功能表示迷惑,在新版本的Glade-3上找不到对应的功能.

新版本的Glade-3是对原先Glade代码的完全重写.一个显著的变化就是去除了代码生成功能.这样做是有原因的,即然代码生成功能不被提倡使用,而是更鼓励使用libglade功能.但是如果你真需要代码生成功能的话,它还是可以做为插件来提供的.另一个显著的不同是glade-3设计用来最大化使用GObject的自省机制(GObject introspection),来使外部工具箱和部件的控制,信号和属性的集成更加容易.

如果看过Say Hello to GTK+的话，可能感觉那样的窗体程序太简单了．那么现在让我们借助Glade弄点儿复杂一点儿的界面吧．首先来瞧瞧Glade长什么样,下图就是Glade在windows下的界面.左边的窗体的小部件选择器，相当于调色板．中间是主菜单，右边的是属性窗体．

现在开始创建一个类似于文本编辑器的图形界面．按照上图标注的顺序，依次添加window部件，vertical box部件,menu bar部件,text view部件和Status部件.vertical box设置三行，它是用来进行界面布局，分割空间用，这是gtk+设计与传统的windows UI设计很不同的地方．后三个部件是放置vertical box中的，最后设计完成图形如下．保存取名为win.glade.如果你感兴趣的话，可以用文件编辑器打开这个文件看看，正如所说的那样，它是一个xml格式的文本文件．

现在我们设置相关的头文件和库文件，编辑一个glade.c文件，添加进以下的代码，运行看看，会出现如上图的对话框．虽然这个对话框什么都不干，但是通过Glade，我们能较为容易地设计界面，而不用通过gtk函数，一个一个将控件实现.

#include <gtk/gtk.h>
#include <glade/glade.h>
int main(int argc, char* argv[])
{
	GladeXML        *gxml;
	GtkWidget       *window;

	gtk_init (&argc, &argv);
	gxml = glade_xml_new ("win.glade", NULL, NULL);
	window = glade_xml_get_widget (gxml, "hello");
	g_object_unref (G_OBJECT (gxml));
	gtk_widget_show (window);                
	gtk_main ();

	return 0;
}

在Windows开发GTK+的应用程序,首先需要其在Windows版本下的库文件,下载gladewin32项目中的gtk+-win32-devel安装包进行安装.我这里使用VS2005进行配置，因为相对于其他的环境，大家对于此IDE更为熟悉．接下来我将一步步介绍我在对GTK/Glande3说Hello时碰到的问题与解决方法．

丑陋的Hello World

任何像我一样急切的人，都希望用最少的代码，看一下GTK+的世界是怎么样的．新建一"Win32 项目",然后向其添加gtk.c文件.

/*  file gtk.c  */ 
#include  < gtk / gtk.h > 

int  main( int  argc,  char *  argv[])
{
    GtkWidget *  window;
    gtk_init ( & argc,  & argv);

    window  =  gtk_window_new (GTK_WINDOW_TOPLEVEL);
    
    gtk_window_set_title (GTK_WINDOW (window),  " Hello World " );
    gtk_widget_show (window);
    gtk_main();

    return   0 ;
} 

现在麻烦的事情到了,设置相关的头文件和库文件.设置头文件,右键点击项目名,然后选择属性.然后在"常规"-"附加包含目录"中设置你安装gtk+-win32-devel时对应的头文件目录.然后再设置库文件,需要gtk-win32-2.0.lib,glib-2.0.lib,gobject-2.0.lib.

设置完好后,你就可以编译运行了,一个什么都不干的丑陋的windows窗体出现你面前了.若编译不通过,缺少某些头文件的话,查看出错信息,然后用windows查找对应头文件路径,再设置.若连接出错,很可能在设置库文件出错了,同理,设置相应的库文件路径.程序代码很简单,定义一个windows窗体指针,然后创建窗体和定义窗体标题,接着就是显示了,和gtk主循环了.

让GTK+有点知觉

或许你发现了，点击窗体中的"X"关闭按钮，虽然窗体消失了，但是黑色的命令窗口还在，发现＂任务管理器＂中程序还在运行着．对，它并没有像你想的那样，在点击"X"关闭按钮结束掉程序．这些是需要你告诉程序该怎么做的．我们需要在代码中添加相应的事件处理函数. 新增加了destroy函数，它就是事件处理函数，在gtk也可叫做信号处理函数，因为gtk中用信号来进行事件的通知．destory函数的形参是有约定写法的，这个大家可以参见具体的手册．在主程序中，还需要将这一函数与具体的信号进行关联，见第17行．

在完成这些工作后，你再点击"X"按钮时，会发现"命令行窗口"会出现"按任意键继续"，程序是真正地退出了.

/* file gtk.c */
#include 
static void destroy( GtkWidget *widget,
                    gpointer   data )
{
    gtk_main_quit ();            //退出gtk主循环
}

int main(int argc, char* argv[])
{

    GtkWidget* window;
    gtk_init (&argc, &argv);

    window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
    
    gtk_window_set_title (GTK_WINDOW (window), "Hello World");
    g_signal_connect (G_OBJECT (window), "destroy",    G_CALLBACK (destroy), NULL);

    gtk_widget_show (window);
    gtk_main();


    return 0;
}

让黑黑的命令行窗口消失

有些人会对这个gtk应用程序总会伴随着黑黑的命令行窗口感到不爽，包括我自己在内．不知道gtk程序在gnome下也是这样，我没有试过，不知道．现在我就使用windows平台的特定方法，来让它消失吧，就是使用WinMain做为主函数．这方法或许不是最正规的做法,但我看来却有效．如果要考虑到跨平台的话，可以用条件编译处理下．

/* file gtk.c */
#include 
#include 
static void destroy( GtkWidget *widget,
                    gpointer   data )
{
    gtk_main_quit ();            //退出gtk主循环
}

int WinMain(HINSTANCE hInstance,
            HINSTANCE hPrevInstance,
            LPSTR lpCmdLine,
            int nCmdShow
            )
{
    //为应付gtk_init所需要的参数
    int argc=1;    
    char* commandLine={"gtkApplication"};
    char** argv = &commandLine;

    GtkWidget* window;
    gtk_init (&argc, &argv);

    window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
    
    gtk_window_set_title (GTK_WINDOW (window), "Hello World");
    g_signal_connect (G_OBJECT (window), "destroy",    G_CALLBACK (destroy), NULL);

    gtk_widget_show (window);
    gtk_main();


    return 0;
}

好啦，现在再编译运行，命令行窗口没有了．你会发现真正的win32窗体了．但是在开发中，我建议用gtk时，还是让命令行窗口显示出来，因为gtk在出错时，会把一些有用的信息打到命令行窗口中，这对你的帮助会很大．

PyGTK让你用Python轻松创建具有图形用户界面的程序.底层的GTK+提供了各式的可视元素和功能,如果需要,你能开发在GNOME桌面系统运行的功能完整的软件.

PyGTK真正具有跨平台性,它能不加修改地,稳定运行各种操作系统之上,如Linux,Windows,MacOS等.除了简单易用和快速的原型开发能力外,PyGTK还有一流的处理本地化语言的独特功能.

PyGTK是自由软件,所以你能几乎没有任何限制的使用，修改，分发，研究它，它是基于LGPL协议发布的．

如果你对上面提到的GTK+,也不了解的话，那允许再对它也进行一番介绍．GTK+，用C语言开发的，具有跨平台的GUI库，它是GNOME桌面系统(如果你在用Linux，一定不陌生)和GIMP图象编辑器的开发工具箱．它是世界上许多程序员的选择，对他们来说，国际化的支持是必要的，而且性能也总是他们考虑的因素．与GTK同一领域的还有Qt库，它是由商业公司开发的C++图形库，虽然它也有免费的．

在windows平台的安装和开发

安装PyGTK只需执行下列步骤：

• 安装Python2.4或以上的windows版本[www.python.org]
• 从GTK+/Glade的windows版本的GTK+ 2.10开发运行时环境[gladewin32.sourceforge.net]
• 从PyGTK网站下载安装PyCairo,PyGobject和PyGTK安装包，注意这些需全部安装才能使PyGTK工作[pygtk.org]

或许你对这些步骤还感到麻烦，或者对Python不熟悉的话，那也没有关系，直接下载一键安装包all-in-one installer,为你配置好全部运行时环境．

看看开发环境是否配置正确，将下列代码作为Python脚本或者在Python交互控制台下输入．如果正确的话，应该有一个标题为"Hello World"的windows的空窗口呈现在你面前．

如果不能运行的话，有可能会出现一个不能成功加载dll的错误提示，这是因为缺少iconv.dll．这时需要只需从网上下载过来，拷贝至windows/system32目录下即可了.

import gtk
window = gtk.Window()
window.set_title("Hello World")
window.show_all()

gtk.main()

FlexeLint for C/C++是在PC_lint在windows平台获得成功后，同样由Gimpel公司开发的，以源代码形式发布的，在Unix/Linux平台上的静态代码分析工具。

本文主要介绍PC-lint的安装与配置，因此是在windows平台上进行讨论。

PC-lint支持几乎所有流行的编译器和IDE环境，可能因为其发展历史和面对专业程序员群体的原因，它是以命令行加配置文件的形式进行使用，所以其使用习惯跟现在常见的windows软件不同。

现以PC-lint与VS2005进行集成来说明：

将PC-lint释放到某一目录下,如:D:\Program Files\pclint.将新建一std.lnt文件在主目录中，并将添加上以下的内容

au-sm.lnt
co-msc80.lnt
lib-mfc.lnt
lib-stl.lnt
lib-w32.lnt
lib-wnt.lnt
lib-atl.lnt
options.lnt  -si4 -sp4

-i "C:\Program Files\Microsoft Visual Studio 8\VC\include"
-i "C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\include"
-i "C:\Program Files\Microsoft Visual Studio 8\VC\PlatformSDK\include"
-i "C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\include"

注意：-i后面为相应的vc头文件目录路径,而一系列xxx.lnt是语法配置规则，决定了按什么规则进行检查，以后可以根据需要进行增减. 写在配置文件中相应的的xxx.lnt从lnt子目录中，拷贝到主目录中．（这一步很重要) 在vs2005中的工具->外部工具中，点击＂添加",新建一个外部工具.标题可以任意，可取(pc_lint)；命令为：D:\Program Files\pclint\LINT-NT.EXE；参数为:-i"D:\Program Files\pclint" std.lnt "$(ItemFileName)$(ItemExt)";初始目录为：$(ItemDir)，并将下面的＂使用输出窗口＂勾选上. 接下来，就可以写一段程序，在工具菜单中选择pc_lint 来进行检查了．如果你编写的程序有不符合定义的规范，则会在输出窗口中出现相关的信息.