How do we describe design patterns? Graphical notations, while important and useful, aren't sufficient. They simply capture the end product of the design process as relationships between classes and objects. To reuse the design, we must also record the decisions, alternatives, and trade-offs that led to it. Concrete examples are important too, because they help you see the design in action.

We describe design patterns using a consistent format. Each pattern is divided into sections according to the following template. The template lends a uniform structure to the information, making design patterns easier to learn, compare, and use.

Pattern Name and Classification

The pattern's name conveys the essence of the pattern succinctly. A good name is vital, because it will become part of your design vocabulary. The pattern's classification reflects the scheme we introduce in Section 1.5.

Intent

A short statement that answers the following questions: What does the design pattern do? What is its rationale and intent? What particular design issue or problem does it address?

Also Known As

Other well-known names for the pattern, if any.

Motivation

A scenario that illustrates a design problem and how the class and object structures in the pattern solve the problem. The scenario will help you understand the more abstract description of the pattern that follows.

Applicability

What are the situations in which the design pattern can be applied? What are examples of poor designs that the pattern can address? How can you recognize these situations?

Structure

A graphical representation of the classes in the pattern using a notation based on the Object Modeling Technique (OMT) [ RBP+91]. We also use interaction diagrams [JCJO92, Boo94] to illustrate sequences of requests and collaborations between objects. Appendix B describes these notations in detail.

Participants

The classes and/or objects participating in the design pattern and their responsibilities.

Collaborations

How the participants collaborate to carry out their responsibilities.

Consequences

How does the pattern support its objectives? What are the trade-offs and results of using the pattern? What aspect of system structure does it let you vary independently?

Implementation

What pitfalls, hints, or techniques should you be aware of when implementing the pattern? Are there language-specific issues?

Sample Code

Code fragments that illustrate how you might implement the pattern in C++ or Smalltalk.

Known Uses

Examples of the pattern found in real systems. We include at least two examples from different domains.

Related Patterns

What design patterns are closely related to this one? What are the important differences? With which other patterns should this one be used?

Christopher Alexander says, "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice" [ AIS+77, page x]. Even though Alexander was talking about patterns in buildings and towns, what he says is true about object-oriented design patterns. Our solutions are expressed in terms of objects and interfaces instead of walls and doors, but at the core of both kinds of patterns is a solution to a problem in a context.

In general, a pattern has four essential elements:

1. The pattern name is a handle we can use to describe a design problem, its solutions, and consequences in a word or two. Naming a pattern immediately increases our design vocabulary. It lets us design at a higher level of abstraction. Having a vocabulary for patterns lets us talk about them with our colleagues, in our documentation, and even to ourselves. It makes it easier to think about designs and to communicate them and their trade-offs to others. Finding good names has been one of the hardest parts of developing our catalog.

2. The problem describes when to apply the pattern. It explains the problem and its context. It might describe specific design problems such as how to represent algorithms as objects. It might describe class or object structures that are symptomatic of an inflexible design. Sometimes the problem will include a list of conditions that must be met before it makes sense to apply the pattern.

3. The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations. The solution doesn't describe a particular concrete design or implementation, because a pattern is like a template that can be applied in many different situations. Instead, the pattern provides an abstract description of a design problem and how a general arrangement of elements (classes and objects in our case) solves it.

4. The consequences are the results and trade-offs of applying the pattern. Though consequences are often unvoiced when we describe design decisions, they are critical for evaluating design alternatives and for understanding the costs and benefits of applying the pattern. The consequences for software often concern space and time trade-offs. They may address language and implementation issues as well. Since reuse is often a factor in object-oriented design, the consequences of a pattern include its impact on a system's flexibility, extensibility, or portability. Listing these consequences explicitly helps you understand and evaluate them.

Point of view affects one's interpretation of what is and isn't a pattern. One person's pattern can be another person's primitive building block. For this book we have concentrated on patterns at a certain level of abstraction. Design patterns are not about designs such as linked lists and hash tables that can be encoded in classes and reused as is. Nor are they complex, domain-specific designs for an entire application or subsystem. The design patterns in this book are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.

A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. The design pattern identifies the participating classes and instances, their roles and collaborations, and the distribution of responsibilities. Each design pattern focuses on a particular object-oriented design problem or issue. It describes when it applies, whether it can be applied in view of other design constraints, and the consequences and trade-offs of its use. Since we must eventually implement our designs, a design pattern also provides sample C++ and (sometimes) Smalltalk code to illustrate an implementation.

Although design patterns describe object-oriented designs, they are based on practical solutions that have been implemented in mainstream object-oriented programming languages like Smalltalk and C++ rather than procedural languages (Pascal, C, Ada) or more dynamic object-oriented languages (CLOS, Dylan, Self). We chose Smalltalk and C++ for pragmatic reasons: Our day-to-day experience has been in these languages, and they are increasingly popular.

The choice of programming language is important because it influences one's point of view. Our patterns assume Smalltalk/C++-level language features, and that choice determines what can and cannot be implemented easily. If we assumed procedural languages, we might have included design patterns called "Inheritance," "Encapsulation," and "Polymorphism." Similarly, some of our patterns are supported directly by the less common object-oriented languages. CLOS has multi-methods, for example, which lessen the need for a pattern such as Visitor (page 331). In fact, there are enough differences between Smalltalk and C++ to mean that some patterns can be expressed more easily in one language than the other. (See Iterator (257) for an example.)

Designing object-oriented software is hard, and designing reusable object-oriented software is even harder. You must find pertinent objects, factor them into classes at the right granularity, define class interfaces and inheritance hierarchies, and establish key relationships among them. Your design should be specific to the problem at hand but also general enough to address future problems and requirements. You also want to avoid redesign, or at least minimize it. Experienced object-oriented designers will tell you that a reusable and flexible design is difficult if not impossible to get "right" the first time. Before a design is finished, they usually try to reuse it several times, modifying it each time.

Yet experienced object-oriented designers do make good designs. Meanwhile new designers are overwhelmed by the options available and tend to fall back on non-object-oriented techniques they've used before. It takes a long time for novices to learn what good object-oriented design is all about. Experienced designers evidently know something inexperienced ones don't. What is it?

One thing expert designers know not to do is solve every problem from first principles. Rather, they reuse solutions that have worked for them in the past. When they find a good solution, they use it again and again. Such experience is part of what makes them experts. Consequently, you'll find recurring patterns of classes and communicating objects in many object-oriented systems. These patterns solve specific design problems and make object-oriented designs more flexible, elegant, and ultimately reusable. They help designers reuse successful designs by basing new designs on prior experience. A designer who is familiar with such patterns can apply them immediately to design problems without having to rediscover them.

An analogy will help illustrate the point. Novelists and playwrights rarely design their plots from scratch. Instead, they follow patterns like "Tragically Flawed Hero" (Macbeth, Hamlet, etc.) or "The Romantic Novel" (countless romance novels). In the same way, object-oriented designers follow patterns like "represent states with objects" and "decorate objects so you can easily add/remove features." Once you know the pattern, a lot of design decisions follow automatically.

We all know the value of design experience. How many times have you had design déjà-vu—that feeling that you've solved a problem before but not knowing exactly where or how? If you could remember the details of the previous problem and how you solved it, then you could reuse the experience instead of rediscovering it. However, we don't do a good job of recording experience in software design for others to use.

The purpose of this book is to record experience in designing object-oriented software as design patterns . Each design pattern systematically names, explains, and evaluates an important and recurring design in object-oriented systems. Our goal is to capture design experience in a form that people can use effectively. To this end we have documented some of the most important design patterns and present them as a catalog.

Design patterns make it easier to reuse successful designs and architectures. Expressing proven techniques as design patterns makes them more accessible to developers of new systems. Design patterns help you choose design alternatives that make a system reusable and avoid alternatives that compromise reusability. Design patterns can even improve the documentation and maintenance of existing systems by furnishing an explicit specification of class and object interactions and their underlying intent. Put simply, design patterns help a designer get a design "right" faster.

None of the design patterns in this book describes new or unproven designs. We have included only designs that have been applied more than once in different systems. Most of these designs have never been documented before. They are either part of the folklore of the object-oriented community or are elements of some successful object-oriented systems—neither of which is easy for novice designers to learn from. So although these designs aren't new, we capture them in a new and accessible way: as a catalog of design patterns having a consistent format.

Despite the book's size, the design patterns in it capture only a fraction of what an expert might know. It doesn't have any patterns dealing with concurrency or distributed programming or real-time programming. It doesn't have any application domain-specific patterns. It doesn't tell you how to build user interfaces, how to write device drivers, or how to use an object-oriented database. Each of these areas has its own patterns, and it would be worthwhile for someone to catalog those too.

• 1.1 引言
• 1.2 CppUnit的简单身世
• 1.3 CppUnit的总体构成
• 1.4 几点说明

• 2.1 基本测试类
  • 2.1.1 Test
  • 2.1.2 TestFixture
  • 2.1.3 TestCase
  • 2.1.4 TestSuite
• 2.2 测试结果记录
  • 2.2.1 SynchronizedObject
  • 2.2.2 TestListener
  • 2.2.3 TestResult
• 2.3 错误处理
  • 2.3.1 TestFailure
  • 2.3.2 SourceLine
  • 2.3.3 Exception
  • 2.3.4 NotEqualException
• 2.4 断言
  • 2.4.1 Asserter
  • 2.4.2 TestAssert

• 3.1 基础部件
  • 3.1.1 Outputter
  • 3.1.2 TestResultCollector
• 3.2 衍生类
  • 3.2.1 TextOutputter
  • 3.2.2 CompilerOutputter
  • 3.2.3 XmlOutputter

• 4.1 创建机制
  • 4.1.1 TypeInfoHelper
  • 4.1.2 TestFactory
  • 4.1.3 TestFactoryRegistry，NamedRegistries
  • 4.1.4 TestSuiteFactory
  • 4.1.5 TestSuiteBuilder
  • 4.1.6 TestCaller
  • 4.1.7 AutoRegisterSuite
• 4.2 HelperMacros

• 5.1 TestDecorator
• 5.2 RepeatedTest
• 5.3 Orthodox
• 5.4 TestSetUp

• 6.1 TestSucessListener
• 6.2 TextTestProgressListener
• 6.3 TextTestResult

• 7.1 TestRunner

• 8.1 OStringStream
• 8.2 其他

• 9.1 WIN32平台安装说明

2003 年 8 月 03 日

本文从开发人员的角度，介绍 CppUnit 框架，希望能够使开发人员用最少的代价尽快掌握这种技术。下面从基本原理，CppUnit 原理，手动使用步骤，通常使用步骤，其他实际问题等方面进行讨论。以下讨论基于 CppUnit1.8.0。

背景

CppUnit 是个基于 LGPL 的开源项目，最初版本移植自 JUnit，是一个非常优秀的开源测试框架。CppUnit 和 JUnit 一样主要思想来源于极限编程（XProgramming）。主要功能就是对单元测试进行管理，并可进行自动化测试。这样描述可能没有让您体会到测试框架的强大威力，那您在开发过程中遇到下列问题吗？如果答案是肯定的，就应该学习使用这种技术：

• 测试代码没有很好地维护而废弃，再次需要测试时还需要重写；
• 投入太多的精力，找 bug，而新的代码仍然会出现类似 bug；
• 写完代码，心里没底，是否有大量 bug 等待自己；
• 新修改的代码不知道是否影响其他部分代码；
• 由于牵扯太多，导致不敢进行修改代码；
  ...

这些问题下文都会涉及。这个功能强大的测试框架在国内的 C++ 语言开发人员中使用的不是很多。本文从开发人员的角度，介绍这个框架，希望能够使开发人员用最少的代价尽快掌握这种技术。下面从基本原理，CppUnit 原理，手动使用步骤，通常使用步骤，其他实际问题等方面进行讨论。以下讨论基于 CppUnit1.8.0。

1. 基本原理

对于上面的问题仅仅说明 CppUnit 的使用是没有效果的，下面先从测试的目的，测试原则等方面简要说明，然后介绍 CppUnit 的具体使用。

首先要明确我们写测试代码的目的，就是验证代码的正确性或者调试 bug。这样写测试代码时就有了针对性，对那些容易出错的，易变的编写测试代码；而不用对每个细节，每个功能编写测试代码，当然除非有过量精力或者可靠性要求。

编码和测试的关系是密不可分的，推荐的开发过程并不要等编写完所有或者很多的代码后再进行测试，而是在完成一部分代码，比如一个函数，之后立刻编写测试代码进行验证。然后再写一些代码，再写测试。每次测试对所有以前的测试都进行一遍。这样做的优点就是，写完代码，也基本测试完一遍，心里对代码有信心。而且在写新代码时不断地测试老代码，对其他部分代码的影响能够迅速发现、定位。不断编码测试的过程也就是对测试代码维护的过程，以便测试代码一直是有效的。有了各个部分测试代码的保证，有了自动测试的机制，更改以前的代码没有什么顾虑了。在极限编程（一种软件开发思想）中，甚至强调先写测试代码，然后编写符合测试代码的代码，进而完成整个软件。

根据上面说的目的、思想，下面总结一下平时开发过程中单元测试的原则：

• 先写测试代码，然后编写符合测试的代码。至少做到完成部分代码后，完成对应的测试代码；
• 测试代码不需要覆盖所有的细节，但应该对所有主要的功能和可能出错的地方有相应的测试用例；
• 发现 bug，首先编写对应的测试用例，然后进行调试；
• 不断总结出现 bug 的原因，对其他代码编写相应测试用例；
• 每次编写完成代码，运行所有以前的测试用例，验证对以前代码影响，把这种影响尽早消除；
• 不断维护测试代码，保证代码变动后通过所有测试；

有上面的理论做指导，测试行为就可以有规可循。那么 CppUnit 如何实现这种测试框架，帮助我们管理测试代码，完成自动测试的？下面就看看 CppUnit 的原理。

2. CppUnit 的原理

在 CppUnit 中，一个或一组测试用例的测试对象被称为 Fixture（设施，下文为方便理解尽量使用英文名称）。Fixture 就是被测试的目标，可能是一个对象或者一组相关的对象，甚至一个函数。

有了被测试的 fixture，就可以对这个 fixture 的某个功能、某个可能出错的流程编写测试代码，这样对某个方面完整的测试被称为TestCase（测试用例）。通常写一个 TestCase 的步骤包括：

1. 对 fixture 进行初始化，及其他初始化操作，比如：生成一组被测试的对象，初始化值；
2. 按照要测试的某个功能或者某个流程对 fixture 进行操作；
3. 验证结果是否正确；
4. 对 fixture 的及其他的资源释放等清理工作。

对 fixture 的多个测试用例，通常（1）（4）部分代码都是相似的，CppUnit 在很多地方引入了 setUp 和 tearDown 虚函数。可以在 setUp 函数里完成（1）初始化代码，而在 tearDown 函数中完成（4）代码。具体测试用例函数中只需要完成（2）（3）部分代码即可，运行时 CppUnit 会自动为每个测试用例函数运行 setUp，之后运行 tearDown，这样测试用例之间就没有交叉影响。

对 fixture 的所有测试用例可以被封装在一个 CppUnit::TestFixture 的子类（命名惯例是[ClassName]Test）中。然后定义这个fixture 的 setUp 和 tearDown 函数，为每个测试用例定义一个测试函数（命名惯例是 testXXX）。下面是个简单的例子：

 class MathTest : public CppUnit::TestFixture {
 protected:
   int m_value1, m_value2;

 public:
   MathTest() {}

	// 初始化函数
   void setUp () {
     m_value1 = 2;
     m_value2 = 3;
   }
   // 测试加法的测试函数
   void testAdd () {
   		// 步骤(2),对 fixture 进行操作
     int result = m_value1 + m_value2;
     	// 步骤(3),验证结果是否争取
     CPPUNIT_ASSERT( result == 5 );
   }
   // 没有什么清理工作没有定义 tearDown. 
 }
 

在测试函数中对执行结果的验证成功或者失败直接反应这个测试用例的成功和失败。CppUnit 提供了多种验证成功失败的方式：

		CPPUNIT_ASSERT(condition)					// 确信condition为真
	CPPUNIT_ASSERT_MESSAGE(message, condition)	// 当condition为假时失败, 并打印message
	CPPUNIT_FAIL(message)						// 当前测试失败, 并打印message
	CPPUNIT_ASSERT_EQUAL(expected, actual)		// 确信两者相等
	CPPUNIT_ASSERT_EQUAL_MESSAGE(message, expected, actual)	// 失败的同时打印message
	CPPUNIT_ASSERT_DOUBLES_EQUAL(expected, actual, delta)	// 当expected和actual之间差大于delta时失败
	

要把对 fixture 的一个测试函数转变成一个测试用例，需要生成一个 CppUnit::TestCaller 对象。而最终运行整个应用程序的测试代码的时候，可能需要同时运行对一个 fixture 的多个测试函数，甚至多个 fixture 的测试用例。CppUnit 中把这种同时运行的测试案例的集合称为 TestSuite。而 TestRunner 则运行测试用例或者 TestSuite，具体管理所有测试用例的生命周期。目前提供了 3 类TestRunner，包括：

		CppUnit::TextUi::TestRunner 	// 文本方式的TestRunner
	CppUnit::QtUi::TestRunner		// QT方式的TestRunner
	CppUnit::MfcUi::TestRunner		// MFC方式的TestRunner
	

下面是个文本方式 TestRunner 的例子：

		CppUnit::TextUi::TestRunner runner;
	CppUnit::TestSuite *suite= new CppUnit::TestSuite();
	
	// 添加一个测试用例
	suite->addTest(new CppUnit::TestCaller<MathTest> (
	              "testAdd", testAdd));
	
	// 指定运行TestSuite 
	runner.addTest( suite );
	// 开始运行, 自动显示测试进度和测试结果
	runner.run( "", true );    // Run all tests and wait
	

对测试结果的管理、显示等功能涉及到另一类对象，主要用于内部对测试结果、进度的管理，以及进度和结果的显示。这里不做介绍。

下面我们整理一下思路，结合一个简单的例子，把上面说的思路串在一起。

3. 手动使用步骤

首先要明确测试的对象 fixture，然后根据其功能、流程，以及以前的经验，确定测试用例。这个步骤非常重要，直接关系到测试的最终效果。当然增加测试用例的过程是个阶段性的工作，开始完成代码后，先完成对功能的测试用例，保证其完成功能；然后对可能出错的部分，结合以前的经验（比如边界值测试、路径覆盖测试等）编写测试用例；最后在发现相关 bug 时，根据 bug 完成测试用例。

比如对整数加法进行测试，首先定义一个新的 TestFixture 子类，MathTest，编写测试用例的测试代码。后期需要添加新的测试用例时只需要添加新的测试函数，根据需要修改 setUp 和 tearDown 即可。如果需要对新的 fixture 进行测试，定义新的 TestFixture 子类即可。注：下面代码仅用来表示原理，不能编译。

/// MathTest.h
// A TestFixture subclass.
// Announce: use as your owner risk.
// Author  : liqun (liqun@nsfocus.com)
// Data    : 2003-7-5

#include "cppunit/TestFixture.h"


class MathTest : public CppUnit::TestFixture {
protected:
	int m_value1, m_value2;
	
public:
	MathTest() {}
	
	// 初始化函数
	void setUp ();
	// 清理函数
	void tearDown();
	
	// 测试加法的测试函数
	void testAdd ();
	// 可以添加新的测试函数
};

/// MathTest.cpp
// A TestFixture subclass.
// Announce: use as your owner risk.
// Author  : liqun (liqun@nsfocus.com)
// Data    : 2003-7-5

#include "MathTest.h"
#include "cppunit/TestAssert.h"

void MathTest::setUp()
{
     m_value1 = 2;
     m_value2 = 3;
}

void MathTest::tearDown()
{

}

void MathTest::testAdd()
{
     int result = m_value1 + m_value2;
     CPPUNIT_ASSERT( result == 5 );
}

然后编写 main 函数，把需要测试的测试用例组织到 TestSuite 中，然后通过 TestRuner 运行。这部分代码后期添加新的测试用例时需要改动的不多。只需要把新的测试用例添加到 TestSuite 中即可。

/// main.cpp
// Main file for cppunit test.
// Announce: use as your owner risk.
// Author  : liqun (liqun@nsfocus.com)
// Data    : 2003-7-5
// Note	   : Cannot compile, only for study.	
#include "MathTest.h"
#include "cppunit/ui/text/TestRunner.h"
#include "cppunit/TestCaller.h"
#include "cppunit/TestSuite.h"

int main()
{
	CppUnit::TextUi::TestRunner runner;
	CppUnit::TestSuite *suite= new CppUnit::TestSuite();
	
	// 添加一个测试用例
	suite->addTest(new CppUnit::TestCaller<MathTest> (
	              "testAdd", testAdd));
	
	// 指定运行TestSuite 
	runner.addTest( suite );
	// 开始运行, 自动显示测试进度和测试结果
	runner.run( "", true );    // Run all tests and wait
}

4. 常用使用方式

按照上面的方式，如果要添加新的测试用例，需要把每个测试用例添加到 TestSuite 中，而且添加新的 TestFixture 需要把所有头文件添加到 main.cpp 中，比较麻烦。为此 CppUnit 提供了 CppUnit::TestSuiteBuilder，CppUnit::TestFactoryRegistry 和一堆宏，用来方便地把 TestFixture 和测试用例注册到 TestSuite 中。下面就是通常的使用方式：

/// MathTest.h
// A TestFixture subclass.
// Announce: use as your owner risk.
// Author  : liqun (liqun@nsfocus.com)
// Data    : 2003-7-5

#include "cppunit/extensions/HelperMacros.h"


class MathTest : public CppUnit::TestFixture {
	// 声明一个TestSuite
	CPPUNIT_TEST_SUITE( MathTest );
	// 添加测试用例到TestSuite, 定义新的测试用例需要在这儿声明一下
	CPPUNIT_TEST( testAdd );
	// TestSuite声明完成
	CPPUNIT_TEST_SUITE_END();
	// 其余不变

protected:
	int m_value1, m_value2;
	
public:
	MathTest() {}
	
	// 初始化函数
	void setUp ();
	// 清理函数
	void tearDown();
	
	// 测试加法的测试函数
	void testAdd ();
	// 可以添加新的测试函数
};

/// MathTest.cpp
// A TestFixture subclass.
// Announce: use as your owner risk.
// Author  : liqun (liqun@nsfocus.com)
// Data    : 2003-7-5

#include "MathTest.h"

// 把这个TestSuite注册到名字为"alltest"的TestSuite中, 如果没有定义会自动定义
// 也可以CPPUNIT_TEST_SUITE_REGISTRATION( MathTest );注册到全局的一个未命名的TestSuite中.
CPPUNIT_TEST_SUITE_NAMED_REGISTRATION( MathTest, "alltest" );

// 下面不变

void MathTest::setUp()
{
     m_value1 = 2;
     m_value2 = 3;
}

void MathTest::tearDown()
{

}

void MathTest::testAdd()
{
     int result = m_value1 + m_value2;
     CPPUNIT_ASSERT( result == 5 );
}


/// main.cpp
// Main file for cppunit test.
// Announce: use as your owner risk.
// Compile : g++ -lcppunit MathTest.cpp main.cpp
// Run     : ./a.out
// Test    : RedHat 8.0 CppUnit1.8.0
// Author  : liqun ( a litthle modification. liqun@nsfocus.com)
// Data    : 2003-7-5

// 不用再包含所有TestFixture子类的头文件
#include <cppunit/extensions/TestFactoryRegistry.h>
#include <cppunit/ui/text/TestRunner.h>

// 如果不更改TestSuite, 本文件后期不需要更改. 

int main()
{
	CppUnit::TextUi::TestRunner runner;
	
	// 从注册的TestSuite中获取特定的TestSuite, 没有参数获取未命名的TestSuite.
	CppUnit::TestFactoryRegistry &registry = CppUnit::TestFactoryRegistry::getRegistry("alltest");
	// 添加这个TestSuite到TestRunner中
	runner.addTest( registry.makeTest() );
	// 运行测试
	runner.run();
}

这样添加新的测试用例只需要在类定义的开始声明一下即可。

5. 其他实际问题

通常包含测试用例代码和被测试对象是在不同的项目中。应该在另一个项目（最好在不同的目录）中编写 TestFixture，然后把被测试的对象包含在测试项目中。

对某个类或者某个函数进行测试的时候，这个 TestFixture 可能引用了别的类或者别的函数，为了隔离其他部分代码的影响，应该在源文件中临时定义一些桩程序，模拟这些类或者函数。这些代码可以通过宏定义在测试项目中有效，而在被测试的项目中无效。

参考资料

• CppUnit 主页
  
  
• JUnitTest Infected: Programmers Love Writing Tests
  
  
• CppUnit Cookbook
  
  
• xprogramming 主页
  
  
• 测试框架
  
  
• 本文代码下载
  

关于作者

		李群，当前关注于网络安全产品的开发、研究；软件开发过程等方面。您可以通过 liqun@nsfocus.com和他联系。

2003 年 1 月 01 日

Skin(表皮) 是制作比较酷的软件界面的有利工具. 一个软件可以同时使用多种Skin 以取得不同的外观, 使同一个软件有截然不同的风格. 用户可以根据自己的喜好选择 不同的风格. 本节介绍使用 Qt 制作 Skin 的方法.

软件界面的风格变化可以通过两种机制完成，一种是通过设置主题(Themes)，它使用 界面库本身所具有的对界面组件(Components)的控制能力切换显示风格；另外一种是 通过提供不同系列的图片来切换显示界面，即这里所讲的 Skin。

制作表皮有几个重要的因素值得考虑：

1. 使用无边界的窗口

在 XWindow 下，无边界的窗口是指不受窗口管理器管理的边界不规则的窗口。由于 不受窗口管理器管理管理，所以软件窗口界面没有附加的标题条(Title Bar)等。 在Qt中，建立无边界窗口的最简单的方法 是设置 QWidget 的 WFlags 的值是 WStyle_NoBorder。它定义在 qnamespace.h 中。 不规则窗口的特点则要求对整个 窗口使用图像掩码。使用 X 窗口形状的扩展(X Shape Extension)来达到要求。在 Qt 中可以直接使用，

                QBitmap bm;
                bm = *(Pixmaps[MASK]);
                setMask(bm);
                setBackgroundPixmap(*Pixmaps[BACKGROUND]);
                

回页首

2. 窗口的移动

由于上述窗口不受窗口管理器的管理的特性，所以移动窗口需要特殊处理，一般的 方法是截取根Widget的鼠标按钮事件，自己处理鼠标点击和移动的事件。

                void SkinDemo::mouseMoveEvent(QMouseEvent *e)
                {
                        QPoint newpos = e->globalPos();
                        QPoint upleft = pos0 + newpos - last;
                        move(upleft);
                }

                void SkinDemo::mousePressEvent(QMouseEvent *e)
                {
                        last = e->globalPos();
                        pos0 = e->globalPos() - e->pos();
                }
                

这里我们取得的鼠标位置是绝对位置，即相对于根窗口的位置，同时也记录下窗口 左上角的位置，当鼠标移动时，取得新的绝对位置，则窗口左上角 的新位置应该 是原来位置与鼠标移动的位置之差。

回页首

3. 按钮的制作

在例子( qt-skin-example.tar.gz)中，我们重新定义了鼠标按下和鼠标移动的事件处理 函数， 并且含有按钮的所有信息，主工作区的所有信息等。主工作区的信息是它的 位置和尺寸，主窗口的信息是它所使用的背景图片和图片的掩码(用来制造不规则窗 口)，所以整个主窗口的大小可以由图片的尺寸来决定。几个按钮的信息包含它们的 位置，它们的大小由图片的大小来决定。

下面是程序运行结果之一：

回页首

回页首

关于作者

		IBM has authored this article

级别: 中级

姚延栋, 研究生, 中国科学院软件所2002级

2003 年 11 月 01 日

本文介绍了如何使用qt提供的接口来设计自己的GUI风格(look and feel)，并通过一个具体的例子(使QSpinBox垂直显示)来详细说明过程。运行环境：redhat 9.0，qt-x11-free-3.2.*

1．Qt的风格

a) Qt简介
Qt是一个跨平台的C++图形用户界面应用程序开发库，使用Qt可以开发出高质量的图形用户接口，它是完全面向对象的、易于扩展且允许真正的组件编程。Qt获得了很大的成功，特别是它的信号-槽机制是非常值得研究的通信机制，它也是Linux发行版标准组件KDE(K Desktop Enviroment)的基础。

b) 风格机制
Qt的风格机制实现了不同平台上的图形用户接口（GUI）的观感（look and feel）,例如Windows平台上通常使用Windows或Windows-xp风格，而Unix平台上通常使用Motif、CDE风格。

下图显示了Qt中与风格相关的类的继承关系

QStyle是所有风格类的基类，它控制着所有的部件（widget即windows编程中的控件）的界面风格或观感，它定义了大量的枚举类型和十几个函数。枚举类型表示界面上的不同元素（如组合框中的按钮，按钮的边框等）；函数控制图形用户界面的绘制，但大多数函数基本上只是一些声明而没有函数实现，他们的实现在QCommonStyle、QWindowStyle、QMotifStyle及其子类中。QStyle只实现了3个函数drawItem(), itemRect(), visualRect()。

drawItem(): 负责绘制文本和象素图。
itemRect(): 返回文本或图像所占的区域。
visualRect(): 返回逻辑坐标，这个函数使Qt实现right-to-left风格（阿文、维文传统是文本从右向左显示，因此控件布局也是从右向左）。如下图所示：

可以看到菜单、工具条是右对齐、单选框的按钮在右边

c) 创建新风格的步骤
在Qt中实现一种新风格的步骤很简单：只需选择一个风格类（如QCommonStyle或QStyle）作为父类，然后实现感兴趣的函数即可。难点在于函数的实现。

选择父类：可以选择QStyle, QCommonStyle, QWindowStyle, QMotifStyle以及他们的子类的任意一个作为父类。通常可以选择QWindowsStyle或QMotifStyle，也可以选择QCommonStyle甚至是QStyle，但是工作量会比较大，因为很多界面的细节需要自己实现。

重新实现必要的函数：想修改界面风格的哪部分，就重新实现与绘制那部分相关的函数，下面解释一下我们要重载的QStyle中的几个函数，这几个函数控制着图形用户界面上不同元素的布局和观感。

                        
1）void drawPrimitive( PrimitiveElement pe,
                    	 QPainter *p,
                        const QRect & r,
                        const QColorGroup & cg,
                        SFlags flags = Style_Default,
                        const QStyleOption &opt = QStyleOption::Default ) ;
                        

功能：绘制基本图形元素，如QSpinBox中的带箭头的按钮 等。

参数： PrimitiveElement pe: 这个枚举型变量表示将要绘制的基本图形界面元素（这里说的基本图形用户界面元素指GUI中不可再分的一个原子元素，如组合框

SFlags flags: 控制如何绘制图形界面元素的标志。
QStyleOption &opt: 绘制不同的部件(widget)时会需要不同的参数，如绘制面板（panel）可能需要线宽作为额外参数而绘制焦点矩形（focus rect）可能需要背景色作为额外参数，所以Qt专门提供了一个类QStyleOption来封装不同的widget可能需要的不同的参数，opt指向这样一个类的对象。

2）void drawComplexControl( 	ComplexControl control,
			QPainter *p,
			const QWidget *widget,
			const QRect &r,
			const QColorGroup &cg,
			SFlags flags = Style_Default,
			SCFlags controls = QStyle::SC_All,
			SCFlags active = QStyle::SC_None,
			const QStyleOption& opt = QStyleOption::Default)
				       			

功能：绘制复杂控制部件（widget）如SpinWidget，comboBox，slider，listView等

参数：

ComplexControl control：是一个枚举量，表示将要绘制的复杂控制部件（widget）如组合框、列表框等。
QPainter *p：指向QPainter的指针，Qt中的所有绘制操作不管是绘制文本、图形还是图像都由这个类来处理。
QWidget *widget：指向QWdget或其子类的指针，可以根据上面control的值转变（cast）成合适的类型，例如如果要绘制QSpinWidget，那么control取值为CC_SpinWidget,而widget指向一个QSpinWidget(QWidget的子类)的实例（instance）。使用这个变量可以访问QSpinWidget的成员函数和成员变量，譬如可以调用QSpinWidget的sizeHint函数获得这个部件的缺省大小（一个矩形空间）。
QRect &r: 表示一个矩形区域，Qt在这个区域中绘制控件或其子部件。
QColorGroup &cg: QColorGroup表示一个部件(widget)的颜色组（color group），color group含有部件绘制自己时使用的各种颜色，譬如前景色背景色等。
SFlags flags: 控制如何绘制图形界面元素的标志
SCFlags controls表示绘制复杂控制部件control的哪个子部件，缺省为SC_All,即绘制整个control而不是其某个子部件（注意control, controls是两个不同的参数）
QStyleOption &opt: 在绘制不同的部件时可能需要不同的额外的参数，这个变量在绘制不同的widget时提供不同的信息。

									
		3) QRect querySubControlMetrics(ComplexControl control,
    								const QWidget* widget,
									SubControl sc,
									const QStyleOption&
									 = QStyleOption::Default)
									

功能：获取子部件的坐标和尺寸信息。这个函数控制着一个复杂控件的布局，重载这个函数可以使的组合框的下拉按钮绘制在左边 而不是默认的右边。

参数：
ComplexControl control: 枚举量，表示将要绘制的复杂控制部件（widget）如组合框、列表框等。
QWidget *widget：指向QWidget或其子类的指针，可以根据上面control的值转变（cast）成合适的类型，例如如果要绘制QSpinWidget，那么control取值为CC_SpinWidget,而widget指向一个QSpinWidget(QWidget的子类)的实例。使用这个变量可以访问QSpinWidget的成员函数和成员变量，譬如可以调用QSpinWidget的sizeHint函数获得这个部件的缺省大小（一个矩形空间）。
SubControl sc：枚举量，一个复杂部件可能由多个的子部件组成，使用sc变量说明要获取那个子部件的坐标和尺寸信息。
QStyleOption &opt: 计算不同部件的尺寸时可能需要不同的额外信息,QStyleOption封装了这些信息。

回页首

2．创建新风格

下面用一个例子来介绍一下创建新风格的整个过程，在编程之前，先看一下最终的结果是什么样的。(在Qt内部QSpinBox类是通过QSpinWidget实现的)

默认风格的效果：

使用新风格的效果：

可以看到在新风格中我们的SpinBox有了垂直显示的效果。下面我们按上面说明的步骤来创建一种新的风格。

1）选择基类：我们选择QWindowsStyle类作为我们新风格类的基类，当然也可以选择QMotifStyle，在这个例子种也可以选择QCommonStyle。一般不建议选择QCommonStyle作为基类，因为QCommonStyle只实现了一部分界面部件，如果要实现一个完整的风格类，我们需要重新写很多代码。

2）重载相关的函数：在这个例程中我们只修改了spinBox的风格，实现这个部件（widget）只与QStyle类的三个函数drawPrimitive, drawComplexControl, qureySubControlMerics相关，所以我们只需重载这三个函数的相关部分代码.下面对代码中的关键部分做一下注释，不重要的部分省略了。详细的代码可以从后面下载。

绘制spinbox中按钮的函数：

void CustomStyle::drawPrimitive( PrimitiveElement pe,
                        	QPainter * p,
                            const QRect & r,
                            const QColorGroup & cg,
                            SFlags flags,
                            const QStyleOption & opt ) const
{
/*PE_SpinWidgetUp,PE_SpinWidgetDown表示spinBox中的下按钮和上按钮，
下面的代码使得这两个按钮中的三角形分别向左和向右*/
if ((pe == PE_SpinWidgetUp) || (pe == PE_SpinWidgetDown)){
		int fw = pixelMetric( PM_DefaultFrameWidth, 0 );//fw表示边框宽度，默认为2
		QRect br;  //spinBox上按钮的边界矩形不是spinBox的边界矩形。
		br.setRect( r.x() + fw, r.y() + fw, r.width() - fw*2,
		    r.height() - fw*2 );
		p->fillRect( br, cg.brush( QColorGroup::Button ) );
		int x = r.x(), y = r.y(), w = r.width(), h = r.height();
		int sw = w-4;
		int sh = sw/2 + 2;      // Must have empty row at foot of arrow
		int sx = x + w / 2 - sw / 2 - 1;
		int sy = y + h / 2 - sh / 2 - 1;

		QPointArray a;
/* 设置三角形的三个点的坐标，修改这三个点可以使得QSpinBox上按钮里的三角型呈现任意的形状，
下面的设置使得三角形表示的箭头分别向左和向右。*/
		if ( pe == PE_SpinWidgetDown )
		    a.setPoints( 3,  0, sh/2,  sw-1, 1,  sw-1, sh-1 );
  	else
	    	a.setPoints( 3,  0, 1,  0, sh-1,  sw-1, sh/2 );
		...........
		p->drawPolygon( a );    //绘制三角形
}else if((pe == PE_ButtonBevel) || (pe == PE_ButtonCommand) || (pe == PE_ButtonTool) 
|| (pe == PE_ButtonDropDown) || (pe == PE_HeaderSection))
    { //绘制按钮的各种效果使得看起来凸起或凹下。
    	qDrawShadePanel(p, r, cg, flags & (Style_Sunken | Style_Down | Style_On), 
		1, &cg.brush(QColorGroup::Button));
    }else{ 
/*对于其他基本图形元素(PrimitiveElement)的绘制我们不作处理只是简单的调用父类的函数。*/
		QWindowsStyle::drawPrimitive( pe, p, r, cg, flags, opt);
    }
}

绘制整个spinBox的函数：

void CustomStyle::drawComplexControl( ComplexControl control,
				       QPainter *p,
				       const QWidget *widget,
				       const QRect &r,
				       const QColorGroup &cg,
				       SFlags flags,
				       SCFlags controls,
				       SCFlags active,
				       const QStyleOption& opt ) const
{    
//下面的代码使得spinWidget呈现垂直显示的风格而不是通常的水平显示
if (control == CC_SpinWidget) {
		const QSpinWidget * sw = (const QSpinWidget *) widget;
		//绘制向上按钮部分，controls默认为SC_All，即绘制整个spinwidget
		if ( controls & SC_SpinWidgetUp ) {
			
	    	if ( sw->buttonSymbols() == QSpinWidget::PlusMinus )
				pe = PE_SpinWidgetPlus;  // 使用加减号

		    else
				pe = PE_SpinWidgetUp;   // 使用三角形 

	    	QRect re = sw->upRect();
		    QColorGroup ucg = sw->isUpEnabled() ? cg : sw->palette().disabled();
	    	drawPrimitive(PE_ButtonBevel, p, re, ucg, flags); //绘制按钮的边框
			drawPrimitive(pe, p, re, ucg, flags); 			//绘制按钮
		}
		//绘制向左按钮部分。
		if ( controls & SC_SpinWidgetDown ) {
		  /*与绘制向下按钮相似*/
		}
}else{//不处理spinbox之外的其他复杂控制部件，调用父类函数处理
QWindowsStyle::drawComplexControl(control, p, widget, r, cg, flags, controls, active, opt);
    }
}

获取部件（widget）中各个子部件布局信息的函数，这个函数控制着一个widget的外观

QRect CustomStyle::querySubControlMetrics( ComplexControl control,
					    const QWidget *widget,
					    SubControl sc,
					    const QStyleOption &opt ) const
{
    if(control == CC_SpinWidget){
    	int fw = pixelMetric( PM_SpinBoxFrameWidth, widget);
/*QSize 定义二维对象的大小,也就是宽和高. 坐标类型是QCOORD定义为int)*/
		QSize bs;  //此处bs表示每个按钮的大小,因为有两个按钮所以下面除以2.
		bs.setWidth(widget->width()/2 -fw);
		if(bs.width() < 8) bs.setWidth(8);
		/*按钮高度设置为QMIN{按钮宽度的1.6倍, 部件高度的四分之一}
		bs.setHeight(  QMIN(bs.width()*8/5, widget->height() / 4) ); 
		bs = bs.expandedTo( QApplication::globalStrut() );
		
		int x = fw;
		int y, ly, ry;
		y = widget->height() - x - bs.height();
		ly = fw;
		ry = y - fw;
	//下面定义了QSpinWidget的各个子部件的坐标位置.
	switch ( sc ) {
	case SC_SpinWidgetUp:
		//返回向右按钮的坐标信息
	    return QRect(x + bs.width(), y, bs.width(), bs.height());
	case SC_SpinWidgetDown:
		//返回向左按钮的坐标信息
	    return QRect(x, y, bs.width(), bs.height());
	case SC_SpinWidgetButtonField:
		//返回两个按钮的总区域大小
	    return QRect(x, y, widget->width() - 2*fw, bs.height());
	case SC_SpinWidgetEditField:
/*返回可编辑框的坐标信息*/
	    return QRect(fw, ly, widget->width() - 2*fw, ry);
	case SC_SpinWidgetFrame:
		//返回整个spinBox的坐标信息
	    return widget->rect();
	default:
	    break;
	}
    }else{//其它部件的布局信息调用父类的函数来处理。
		return QWindowsStyle::querySubControlMetrics(control,widget,sc,opt );
    }
    return QRect();
}

回页首

3．使用新风格

有两种方法使用新风格，一种是作为插件，一种是在应用程序里直接使用。作为插件的风格可以在不用修改代码、不用重新编译的情况下使用新风格。由于本文着重介绍如何创建风格所以我们使用第一种方法。这种方法很简单，只需在应用程序中包含相应风格类的头文件，然后把main（）函数第一句可执行代码设置为QApplication::setStyle(new MyStyle())即可。

下面我们用一个小例子来看看效果。

#include <qapplication.h>
#include <qspinbox.h>
#include "customstyle.h"
int main( int argc, char **argv )
{
    QApplication::setStyle(new CustomStyle()); //使用新风格类来绘制界面。
    QApplication a( argc, argv );
    QSpinBox spin( 0, 15 );
    spin.resize( 20, 100 );
    a.setMainWidget( &spin );
    spin.show();
    return a.exec();
}

然后编译运行即可看到效果。

Ps. qt中编译使用qmake，步骤为

• 创建源程序
• 同一目录下运行qmake -project
• qmake
• make
• 运行可执行程序。

回页首

4．进一步工作

1）默认大小：细心的朋友可能看到上面的代码中有一句：spin.resize( 20, 100 )，这一句设置spinbox的长度为20象素，宽度为100个象素。如果没有这一句的话，显示的结果会一团糟，两个按钮几乎看不到

，因为qt默认的显示是水平显示而根本没有考虑垂直显示的情况。

如果想让spinbox在默认情况下看起来长度窄而宽度高需要修改QSpinBox类中的sizeHint函数，这个函数功能是设置部件(widget)的默认尺寸。在qt中几乎每个GUI部件类都有sizeHint这个函数来设置它自己的默认的长和宽。

文本垂直显示：在此例中虽然控件spinbox达到了垂直显示的效果，但是文本仍旧是水平显示的，因此要达到真正的垂直显示需要了解qt的文本显示机制。这些工作是很有意义的，因为有些民族（如蒙文）的语言传统就是垂直显示的，而现在没有一个真正满足这种需求的系统。笔者现在正在看qt-x11-free-3.2.2的源码，目前对文本显示机制只有初步了解，还没有真正弄清，非常希望和感兴趣的朋友相互交流、学习。

回页首

参考资料

• 实例 源代码下载
  
  
• Qt官方文档 http://doc.trolltech.com/3.2/index.html
  
  
• Qt源代码:QStyle, QCommonStyle,QSpinWidget,QSpinBox从中可以了解很多的细节.
  

回页首

关于作者

		姚延栋：中国科学院软件所2002级研究生，方向为系统软件和中文信息处理，对复杂文本处理和系统编程(Qt, Gtk等)很感兴趣，联系方式： ydyao@mails.gscas.ac.cn

2004 年 4 月 01 日

Qt 作为一种基于 C++ 的跨平台 GUI 系统，能够提供给用户构造图形用户界面的强大功能。为了满足用户构造复杂图形界面系统的需求，Qt 提供了丰富的多线程编程支持。

Qt 作为一种基于 C++ 的跨平台 GUI 系统，能够提供给用户构造图形用户界面的强大功能。为了满足用户构造复杂图形界面系统的需求，Qt 提供了丰富的多线程编程支持。从 2.2 版本开始，Qt 主要从下面三个方面对多线程编程提供支持：一、构造了一些基本的与平台无关的线程类；二、提交用户自定义事件的 Thread-safe 方式；三、多种线程间同步机制，如信号量，全局锁。这些都给用户提供了极大的方便。不过，在某些情况下，使用定时器机制能够比利用 Qt 本身的多线程机制更方便地实现所需要的功能，同时也避免了不安全的现象发生。本文不仅对 Qt 中的多线程支持机制进行了讨论，还着重探讨了利用定时器机制模拟多线程编程的方法。

1、系统对多线程编程的支持

不同的平台对 Qt 的多线程支持方式是不同的。当用户在 Windows 操作系统上安装 Qt 系统时，线程支持是编译器的一个选项，在 Qt 的 mkfiles 子目录中包括了不同种类编译器的编译文件，其中带有 -mt 后缀的文件才是支持多线程的。

而在 Unix 操作系统中，线程的支持是通过在运行 configure 脚本文件时添加 -thread 选项加入的。安装过程将创建一个独立的库，即 libqt-mt，因此要支持多线程编程时，必须与该库链接（链接选项为-lqt-mt），而不是与通常的 Qt 库（-lqt）链接。

另外，无论是何种平台，在增加线程支持时都需要定义宏 QT_THREAD_SUPPORT（即增加编译选项-DQT_THREAD_SUPPORT）。在 Windows 操作系统中，这一点通常是在 qconfig.h 文件中增加一个选项来实现的。而在 Unix 系统中通常添加在有关的 Makefile 文件中。

回页首

2、Qt中的线程类

在 Qt 系统中与线程相关的最重要的类当然是 QThread 类，该类提供了创建一个新线程以及控制线程运行的各种方法。线程是通过 QThread::run() 重载函数开始执行的，这一点很象 Java 语言中的线程类。在 Qt 系统中，始终运行着一个GUI 主事件线程，这个主线程从窗口系统中获取事件，并将它们分发到各个组件去处理。在 QThread 类中还有一种从非主事件线程中将事件提交给一个对象的方法，也就是 QThread::postEvent()方法，该方法提供了 Qt 中的一种 Thread-safe 的事件提交过程。提交的事件被放进一个队列中，然后 GUI 主事件线程被唤醒并将此事件发给相应的对象，这个过程与一般的窗口系统事件处理过程是一样的。值得注意的是，当事件处理过程被调用时，是在主事件线程中被调用的，而不是在调用QThread::postEvent 方法的线程中被调用。比如用户可以从一个线程中迫使另一个线程重画指定区域：

QWidget *mywidget;
QThread::postEvent(mywidget, new QPaintEvent(QRect(0,0,100,100)));

                

然而，只有一个线程类是不够的，为编写出支持多线程的程序，还需要实现两个不同的线程对共有数据的互斥访问，因此 Qt 还提供了 QMutex 类，一个线程在访问临界数据时，需要加锁，此时其他线程是无法对该临界数据同时加锁的，直到前一个线程释放该临界数据。通过这种方式才能实现对临界数据的原子操作。

除此之外，还需要一些机制使得处于等待状态的线程在特定情况下被唤醒。QWaitCondition 类就提供了这种功能。当发生特定事件时，QWaitCondition 将唤醒等待该事件的所有线程或者唤醒任意一个被选中的线程。

回页首

3、用户自定义事件在多线程编程中的应用

在 Qt 系统中，定义了很多种类的事件，如定时器事件、鼠标移动事件、键盘事件、窗口控件事件等。通常，事件都来自底层的窗口系统，Qt 的主事件循环函数从系统的事件队列中获取这些事件，并将它们转换为 QEvent，然后传给相应的 QObjects 对象。

除此之外，为了满足用户的需求，Qt 系统还提供了一个 QCustomEvent 类，用于用户自定义事件，这些自定义事件可以利用 QThread::postEvent() 或者QApplication::postEvent() 被发给各种控件或其他 QObject 实例，而 QWidget 类的子类可以通过 QWidget::customEvent() 事件处理函数方便地接收到这些自定义的事件。需要注意的是：QCustomEvent 对象在创建时都带有一个类型标识 id 以定义事件类型，为了避免与 Qt 系统定义的事件类型冲突，该 id 值应该大于枚举类型 QEvent::Type 中给出的 "User" 值。

在下面的例子中，显示了多线程编程中如何利用用户自定义事件类。

UserEvent类是用户自定义的事件类，其事件标识为346798，显然不会与系统定义的事件类型冲突。

class UserEvent : public QCustomEvent   //用户自定义的事件类
{
public:
 UserEvent(QString s) : QCustomEvent(346798), sz(s) { ; }
 QString str() const { return sz; }
private:
 QString sz;    
};

                

UserThread类是由QThread类继承而来的子类，在该类中除了定义有关的变量和线程控制函数外，最主要的是定义线程的启动函数UserThread::run()，在该函数中创建了一个用户自定义事件UserEvent，并利用QThread类的postEvent函数提交该事件给相应的接收对象。

class UserThread : public QThread      //用户定义的线程类
{
public:
 UserThread(QObject *r, QMutex *m, QWaitCondition *c);
QObject *receiver;
}

void UserThread::run()     //线程类启动函数，在该函数中创建了一个用户自定义事件
{UserEvent *re = new UserEvent(resultstring);
   QThread::postEvent(receiver, re); 
}

                

UserWidget类是用户定义的用于接收自定义事件的QWidget类的子类，该类利用slotGo()函数创建了一个新的线程recv（UserThread类），当收到相应的自定义事件（即id为346798）时，利用customEvent函数对事件进行处理。

void UserWidget::slotGo()    //用户定义控件的成员函数
{ mutex.lock();  
 if (! recv)
  recv = new UserThread(this, &mutex, &condition);
 recv->start();
 mutex.unlock();
}

void UserWidget::customEvent(QCustomEvent *e)   //用户自定义事件处理函数
{ if (e->type()==346798) 
 {
  UserEvent *re = (UserEvent *) e;
        newstring = re->str();
    }
}

                

在这个例子中，UserWidget对象中创建了新的线程UserThread，用户可以利用这个线程实现一些周期性的处理（如接收底层发来的消息等），一旦满足特定条件就提交一个用户自定义的事件，当UserWidget对象收到该事件时，可以按需求做出相应的处理，而一般情况下，UserWidget对象可以正常地执行某些例行处理，而完全不受底层消息的影响。

回页首

4、利用定时器机制实现多线程编程

为了避免Qt系统中多线程编程带来的问题，还可以使用系统中提供的定时器机制来实现类似的功能。定时器机制将并发的事件串行化，简化了对并发事件的处理，从而避免了thread-safe方面问题的出现。

在下面的例子中，同时有若干个对象需要接收底层发来的消息（可以通过Socket、FIFO等进程间通信机制），而消息是随机收到的，需要有一个GUI主线程专门负责接收消息。当收到消息时主线程初始化相应对象使之开始处理，同时返回，这样主线程就可以始终更新界面显示并接收外界发来的消息，达到同时对多个对象的控制；另一方面，各个对象在处理完消息后需要通知GUI主线程。对于这个问题，可以利用第3节中的用户自定义事件的方法，在主线程中安装一个事件过滤器，来捕捉从各个对象中发来的自定义事件，然后发出信号调用主线程中的一个槽函数。

另外，也可以利用Qt中的定时器机制实现类似的功能，而又不必担心Thread-safe问题。下面就是有关的代码部分：

在用户定义的Server类中创建和启动了定时器，并利用connect函数将定时器超时与读取设备文件数据相关联：

Server:: Server(QWidget *parent) : QWidget(parent)
{
readTimer = new QTimer(this);   //创建并启动定时器
   connect(readTimer, SIGNAL(timeout()), this, SLOT(slotReadFile()));   //每当定时器超时时调用函数slotReadFile读取文件
   readTimer->start(100);
}

                

slotReadFile函数负责在定时器超时时，从文件中读取数据，然后重新启动定时器：

int Server::slotReadFile()    // 消息读取和处理函数
{
  readTimer->stop();     //暂时停止定时器计时
  ret = read(file, buf );   //读取文件
if(ret == NULL)
{    readTimer->start(100);     //当没有新消息时，重新启动定时器
    return(-1);
}
  else
       根据buf中的内容将消息分发给各个相应的对象处理……；
readTimer->start(100);    //重新启动定时器
}

                

在该程序中，利用了类似轮循的方式定时对用户指定的设备文件进行读取，根据读到的数据内容将信息发送到各个相应的对象。用户可以在自己的GUI主线程中创建一个Server类，帮助实现底层的消息接收过程，而本身仍然可以处理诸如界面显示的问题。当各个对象完成处理后，通过重新启动定时器继续进行周期性读取底层设备文件的过程。当然，这种方法适合于各对象对事件的处理时间较短，而底层设备发来消息的频率又相对较慢的情况。在这种情况下，上述方法完全可以满足用户的需求，而又避免了处理一些与线程并发有关的复杂问题。

当然，利用定时器机制实现多线程编程在某些方面具有一定的局限性，有关到底如何实现多线程编程，如何编写出效率更高的代码，还有待于开发者进一步研究和探讨。

回页首

参考资料

（1）Qt官方文档 http://doc.trolltech.com/3.2/index.html

（2）Qt源代码:QThread, QCustomEvent,QTimer.

（3）Advanced Programming in the UNIX Environment, W. Richard Stevens.

回页首

关于作者

		续欣：联系方式 xxin76@hotmail.com。 转自 http://www-128.ibm.com/developerworks/cn/linux/l-qt-mthrd/index.html

• Incremental searching of files throughout the workspace, global include/source directories, or user specified directories.
• Incremental tag searches either by identifier name or a parent class or namespace.
• Switching between the declaration and definition of functions.
• Tag completion at the press of a key while typing.
• Powerful code templates.
• And a whole lot more...

Workspace Whiz! is chock full of useful features. This tour provides an overview of the most major Workspace Whiz! features.

• Finding files anywhere in the workspace
• File context menu
• Adding external projects and workspaces
• "Alternate" file swapping
• Opening global include and source files
• Finding tags anywhere in the workspace
• Other tag uses
• Tag scope
• Automatic tag completion
• Record of movement
• Code templates overview
• Template files
• Programming interface

http://www.workspacewhiz.com/index.html