Google C++ Testing Framework Primer

翻译：Ray Li (ray.leex@gmail.com)
修改日期：2008年7月6日
原文参见：http://code.google.com/p/googletest/wiki/GoogleTestPrimer

Introduction：为什么需要Google C++ 测试框架？

Google C++ 测试框架帮助你更好地编写C++测试。

无论你是在Linux，Windows，还是Mac环境下工作，只要你编写C++代码，Google 测试框架都可以帮上忙。

那么，哪些因素才能构成一个好的测试？以及，Google C++ 测试框架怎样满足这些因素？我们相信：

1. 测试应该是独立、可重复的。因为其他测试成功或失败而导致我们要对自己的测试进行debug是非常痛苦的。Google C++ 测试框架通过将每个测试在不同的对象中运行，使得测试分离开来。当一个测试失败时，Google C++ 测试框架允许你独立运行它以进行快速除错。
2. 测试应该能够被很好地组织，并反映被测代码的结构。Google C++ 测试框架将测试组织成测试案例，案例中的测试可以共享数据和程序分支。这样一种通用模式能够很容易辨识，使得我们的测试容易维护。当开发人员在项目之间转换，开始在一个新的代码基上开始工作时，这种一致性格外有用。
3. 测试应该是可移植、可重用的。开源社区有很多平台独立的代码，它们的测试也应该是平台独立的。除开一些特殊情况，Google C++ 测试框架运行在不同的操作系统上、与不同的编译器（gcc、icc、MSVC）搭配，Google C++ 测试框架的测试很容易与不同的配置一起工作。
4. 当测试失败时，应该提供尽可能多的、关于问题的信息。Google C++ 测试框架在第一个测试失败时不会停下来。相反，它只是将当前测试停止，然后继续接下来的测试。你也可以设置对一些非致命的错误进行报告，并接着进行当前的测试。这样，你就可以在一次“运行-编辑-编译”循环中检查到并修复多个bug。
5. 测试框架应该能将测试编写人员从一些环境维护的工作中解放出来，使他们能够集中精力于测试的内容。Google C++ 测试框架自动记录下所有定义好的测试，不需要用户通过列举来指明哪些测试需要运行。
6. 测试应该快速。使用Google C++ 测试框架，你可以重用多个测试的共享资源，一次性完成设置/解除设置，而不用使一个测试去依赖另一测试。

因为Google C++ 测试框架基于著名的xUnit架构，如果你之前使用过JUnit或PyUnit的话，你将会感觉非常熟悉。如果你没有接触过这些测试框架，它也只会占用你大约10分钟的时间来学习基本概念和上手。所以，让我们开始吧！

Note：本文偶尔会用“Google Test”来代指“Google C++ 测试框架”。

基本概念

使用Google Test时，你是从编写断言开始的，而断言是一些检查条件是否为真的语句。一个断言的结果可能是成功、非致命失败，或者致命失败。如果一个致命失败出现，他会结束当前的函数；否则，程序继续正常运行。

测试使用断言来验证被测代码的行为。如果一个测试崩溃或是出现一个失败的断言，那么，该测试失败；否则该测试成功。

一个测试案例（test case）包含了一个或多个测试。你应该将自己的测试分别归类到测试案例中，以反映被测代码的结构。当测试案例中的多个测试需要共享通用对象和子程序时，你可以把他们放到一个测试固件（test fixture）类中。

一个测试程序可以包含多个测试案例。

从编写单个的断言开始，到创建测试和测试案例，我们将会介绍怎样编写一个测试程序。

断言

Google Test中的断言是一些与函数调用相似的宏。要测试一个类或函数，我们需要对其行为做出断言。当一个断言失败时，Google Test会在屏幕上输出该代码所在的源文件及其所在的位置行号，以及错误信息。也可以在编写断言时，提供一个自定义的错误信息，这个信息在失败时会被附加 在Google Test的错误信息之后。

断言常常成对出现，它们都测试同一个类或者函数，但对当前功能有着不同的效果。ASSERT_*版本的断言失败时会产生致命失败，并结束当前函数。EXPECT_*版本的断言产生非致命失败，而不会中止当前函数。通常更推荐使用EXPECT_*断言，因为它们运行一个测试中可以有不止一个的错误被报告出来。但如果在编写断言如果失败，就没有必要继续往下执行的测试时，你应该使用ASSERT_*断言。

因为失败的ASSERT_*断言会立刻从当前的函数返回，可能会跳过其后的一些的清洁代码，这样也许会导致空间泄漏。根据泄漏本身的特质，这种情况 也许值得修复，也可能不值得我们关心——所以，如果你得到断言错误的同时，还得到了一个堆检查的错误，记住上面我们所说的这一点。

要提供一个自定义的错误消息，只需要使用<<操作符，或一个<<操作符的序列，将其输入到框架定义的宏中。下面是一个例子：

Cpp代码

1. ASSERT_EQ(x.size(), y.size()) << "Vectors x and y are of unequal length";   
2. for (int i = 0; i < x.size(); ++i) {   
3.    EXPECT_EQ(x[i], y[i]) << "Vectors x and y differ at index " << i;   
4. }  

ASSERT_EQ(x.size(), y.size()) << "Vectors x and y are of unequal length";
for (int i = 0; i < x.size(); ++i) {
  EXPECT_EQ(x[i], y[i]) << "Vectors x and y differ at index " << i;
}

任何能够被输出到ostream中的信息都可以被输出到一个断言宏中——特别是C字符串和string对象。如果一个宽字符串 （wchar_t*，windows上UNICODE模式TCHAR*或std::wstring）被输出到一个断言中，在打印时它会被转换成UTF-8 编码。

基本断言

下面这些断言实现了基本的true/false条件测试。

致命断言
非致命断言
验证条件

ASSERT_TRUE(condition);
EXPECT_TRUE(condition);
condition为真

ASSERT_FALSE(condition);
EXPECT_FALSE(condition);
condition 为假

记住，当它们失败时，ASSERT_*产生一个致命失败并从当前函数返回，而EXCEPT_*产生一个非致命失败，允许函数继续运行。在两种情况下，一个断言失败都意味着它所包含的测试失败。

有效平台：Linux、Windows、Mac。

二进制比较

本节描述了比较两个值的一些断言。

致命断言
非致命断言
验证条件

ASSERT_EQ(expected, actual);
EXPECT_EQ(expected, actual);
expected == actual

ASSERT_NE(val1, val2);
EXPECT_NE(val1, val2);
val1 != val2

ASSERT_LT(val1, val2);
EXPECT_LT(val1, val2);
val1 < val2

ASSERT_LE(val1, val2);
EXPECT_LE(val1, val2);
val1 <= val2

ASSERT_GT(val1, val2);
EXPECT_GT(val1, val2);
val1 > val2

ASSERT_GE(val1, val2);
EXPECT_GE(val1, val2);
val1 >= val2

在出现失败事件时，Google Test会将两个值（Val1和Val2）都打印出来。在ASSERT_EQ*和EXCEPT_EQ*断言（以及我们随后介绍类似的断言）中，你应该把你希望测试的表达式放在actual（实际值）的位置上，将其期望值放在expected（期望值）的位置上，因为Google Test的测试消息为这种惯例做了一些优化。

参数值必须是可通过断言的比较操作符进行比较的，否则你会得到一个编译错误。参数值还必须支持<<操作符来将值输入到ostream中。所有的C++内置类型都支持这一点。

这些断言可以用于用户自定义的型别，但你必须重载相应的比较操作符（如==、<等）。如果定义有相应的操作符，推荐使用ASSERT_*()宏，因为它们不仅会输出比较的结果，还会输出两个比较对象。

参数表达式总是只被解析一次。因此，参数表达式有一定的副作用（side effect，这里应该是指编译器不同，操作符解析顺序的不确定性）也是可以接受的。但是，同其他普通C/C++函数一样，参数表达式的解析顺序是不确定 的（如，一种编译器可以自由选择一种顺序来进行解析），而你的代码不应该依赖于某种特定的参数解析顺序。

ASSERT_EQ()对指针进行的是指针比较。即，如果被用在两个C字符串上，它会比较它们是否指向同样的内存地址，而不是它们所指向的字符串是 否有相同值。所以，如果你想对两个C字符串（例如，const char*）进行值比较，请使用ASSERT_STREQ()宏，该宏会在后面介绍到。特别需要一提的是，要验证一个C字符串是否为空（NULL），使用 ASSERT_STREQ(NULL, c_string)。但是要比较两个string对象时，你应该使用ASSERT_EQ。

本节中介绍的宏都可以处理窄字符串对象和宽字符串对象（string和wstring）。

有效平台：Linux、Windows、Mac。

字符串比较

该组断言用于比较两个C字符串。如果你想要比较两个string对象，相应地使用EXPECT_EQ、EXPECT_NE等断言。

致命断言
非致命断言
验证条件

ASSERT_STREQ(expected_str, actual_str);
EXPECT_STREQ(expected_str, actual_str);
两个C字符串有相同的内容

ASSERT_STRNE(str1, str2);
EXPECT_STRNE(str1, str2);
两个C字符串有不同的内容

ASSERT_STRCASEEQ(expected_str, actual_str);
EXPECT_STRCASEEQ(expected_str, actual_str);
两个C字符串有相同的内容，忽略大小写

ASSERT_STRCASENE(str1, str2);
EXPECT_STRCASENE(str1, str2);
两个C字符串有不同的内容，忽略大小写

注意断言名称中出现的“CASE”意味着大小写被忽略了。

*STREQ*和*STRNE*也接受宽字符串（wchar_t*）。如果两个宽字符串比较失败，它们的值会做为UTF-8窄字符串被输出。

一个NULL空指针和一个空字符串会被认为是不一样的。

有效平台：Linux、Windows、Mac。

参见：更多的字符串比较的技巧（如子字符串、前缀和正则表达式匹配），请参见[Advanced Guide Advanced Google Test Guide]。

简单的测试

要创建一个测试：

1. 使用TEST（）宏来定义和命名一个测试函数，它们是一些没有返回值的普通C++函数。
2. 在这个函数中，与你想要包含的其它任何有效C++代码一起，使用Google Test提供的各种断言来进行检查。
3. 测试的结果由其中的断言决定；如果测试中的任意断言失败（无论是致命还是非致命），或者测试崩溃，那么整个测试就失败了。否则，测试通过。

Cpp代码

1. TEST(test_case_name, test_name) {   
2. ... test body ...   
3. }  

TEST(test_case_name, test_name) {
... test body ...
}

TEST（）的参数是从概括到特殊的。第一个参数是测试案例的名称，第二个参数是测试案例中的测试的名称。记住，一个测试案例可以包含任意数量的独立测试。一个测试的全称包括了包含它的测试案例名称，及其独立的名称。不同测试案例中的独立测试可以有相同的名称。

举例来说，让我们看一个简单的整数函数：

Cpp代码

1. int Factorial(int n); // 返回n的阶乘

int Factorial(int n); // 返回n的阶乘

这个函数的测试案例应该看起来像是：

Cpp代码

1. // 测试0的阶乘
2. TEST(FactorialTest, HandlesZeroInput) {   
3.    EXPECT_EQ(1, Factorial(0));   
4. }   
5. // 测试正数的阶乘
6. TEST(FactorialTest, HandlesPositiveInput) {   
7.    EXPECT_EQ(1, Factorial(1));   
8.    EXPECT_EQ(2, Factorial(2));   
9.    EXPECT_EQ(6, Factorial(3));   
10.    EXPECT_EQ(40320, Factorial(8));   
11. }  

// 测试0的阶乘
TEST(FactorialTest, HandlesZeroInput) {
  EXPECT_EQ(1, Factorial(0));
}
// 测试正数的阶乘
TEST(FactorialTest, HandlesPositiveInput) {
  EXPECT_EQ(1, Factorial(1));
  EXPECT_EQ(2, Factorial(2));
  EXPECT_EQ(6, Factorial(3));
  EXPECT_EQ(40320, Factorial(8));
}

Google Test根据测试案例来分组收集测试结果，因此，逻辑相关的测试应该在同一测试案例中；换句话说，它们的TEST（）的第一个参数应该是一样的。在上面的 例子中，我们有两个测试，HandlesZeroInput和HandlesPostiveInput，它们都属于同一个测试案例 FactorialTest。

有效平台：Linux、Windows、Mac。

测试固件（Test Fixtures，又做测试夹具、测试套件）：在多个测试中使用同样的数据配置

当你发现自己编写了两个或多个测试来操作同样的数据，你可以采用一个测试固件。它让你可以在多个不同的测试中重用同样的对象配置。

要创建测试固件，只需：

1. 创建一个类继承自testing::Test。将其中的成员声明为protected:或是public:，因为我们想要从子类中存取固件成员。
2. 在该类中声明你计划使用的任何对象。
3. 如果需要，编写一个默认构造函数或者SetUp()函数来为每个测试准备对象。常见错误包括将SetUp()拼写为Setup()（小写了u）——不要让它发生在你身上。
4. 如果需要，编写一个析构函数或者TearDown()函数来释放你在SetUp()函数中申请的资源。要知道什么时候应该使用构造函数/析构函数，什么时候又应该使用SetUp()/TearDown()函数，阅读我们的FAQ。
5. 如果需要，定义你的测试所需要共享的子程序。

当我们要使用固件时，使用TEST_F()替换掉TEST()，它允许我们存取测试固件中的对象和子程序：

Cpp代码

1. TEST_F(test_case_name, test_name) {   
2. ... test body ...   
3. }  

TEST_F(test_case_name, test_name) {
... test body ...
}

与TEST()一样，第一个参数是测试案例的名称，但对TEST_F()来说，这个名称必须与测试固件类的名称一些。你可能已经猜到了：_F正是指固件。

不幸地是，C++宏系统并不允许我们创建一个单独的宏来处理两种类型的测试。使用错误的宏会导致编译期的错误。

而且，你必须在TEST_F()中使用它之前，定义好这个测试固件类。否则，你会得到编译器的报错：“virtual outside class declaration”。

对于TEST_F()中定义的每个测试，Google Test将会：

1. 在运行时创建一个全新的测试固件
2. 马上通过SetUp()初始化它，
3. 运行测试
4. 调用TearDown()来进行清理工作
5. 删除测试固件。注意，同一测试案例中，不同的测试拥有不同的测试固件。Google Test在创建下一个测试固件前总是会对现有固件进行删除。Google Test不会对多个测试重用一个测试固件。测试对测试固件的改动并不会影响到其他测试。

例如，让我们为一个名为Queue的FIFO队列类编写测试，该类的接口如下：

Cpp代码

1. template <typename E> // E为元素类型
2. class Queue {   
3. public:   
4.    Queue();   
5. void Enqueue(const E& element);   
6.    E* Dequeue(); // 返回 NULL 如果队列为空.
7. size_t size() const;   
8.    ...   
9. };  

template <typename E> // E为元素类型
class Queue {
public:
  Queue();
  void Enqueue(const E& element);
  E* Dequeue(); // 返回 NULL 如果队列为空.
  size_t size() const;
  ...
};

首先，定义一个固件类。习惯上，你应该把它的名字定义为FooTest，这里的Foo是被测试的类。

Cpp代码

1. class QueueTest : public testing::Test {   
2. protected:   
3. virtual void SetUp() {   
4.      q1_.Enqueue(1);   
5.      q2_.Enqueue(2);   
6.      q2_.Enqueue(3);   
7.    }   
8. // virtual void TearDown() {}
9.    Queue<int> q0_;   
10.    Queue<int> q1_;   
11.    Queue<int> q2_;   
12. };  

class QueueTest : public testing::Test {
protected:
  virtual void SetUp() {
    q1_.Enqueue(1);
    q2_.Enqueue(2);
    q2_.Enqueue(3);
  }
  // virtual void TearDown() {}
  Queue<int> q0_;
  Queue<int> q1_;
  Queue<int> q2_;
};

在这个案例中，我们不需要TearDown()，因为每个测试后除了析构函数外不需要进行其它的清理工作了。

接下来我们使用TEST_F()和这个固件来编写测试。

Cpp代码

1. TEST_F(QueueTest, IsEmptyInitially) {   
2.    EXPECT_EQ(0, q0_.size());   
3. }   
4. TEST_F(QueueTest, DequeueWorks) {   
5. int* n = q0_.Dequeue();   
6.    EXPECT_EQ(NULL, n);   
7. 
   
8.    n = q1_.Dequeue();   
9.    ASSERT_TRUE(n != NULL);   
10.    EXPECT_EQ(1, *n);   
11.    EXPECT_EQ(0, q1_.size());   
12. delete n;   
13. 
    
14.    n = q2_.Dequeue();   
15.    ASSERT_TRUE(n != NULL);   
16.    EXPECT_EQ(2, *n);   
17.    EXPECT_EQ(1, q2_.size());   
18. delete n;   
19. }  

TEST_F(QueueTest, IsEmptyInitially) {
  EXPECT_EQ(0, q0_.size());
}
TEST_F(QueueTest, DequeueWorks) {
  int* n = q0_.Dequeue();
  EXPECT_EQ(NULL, n);

  n = q1_.Dequeue();
  ASSERT_TRUE(n != NULL);
  EXPECT_EQ(1, *n);
  EXPECT_EQ(0, q1_.size());
  delete n;

  n = q2_.Dequeue();
  ASSERT_TRUE(n != NULL);
  EXPECT_EQ(2, *n);
  EXPECT_EQ(1, q2_.size());
  delete n;
}

上面这段代码既使用了ASSERT_*断言，又使用了EXPECT_*断言。经验上讲，如果你想要断言失败后，测试能够继续进行以显示更多的错误 时，你应该使用EXPECT_*断言；使用ASSERT_*如果该断言失败后继续往下执行毫无意义。例如，Dequeue测试中的第二个断言是 ASSERT_TURE(n!= NULL)，因为我们随后会n指针解引用，如果n指针为空的话，会导致一个段错误。

当这些测试开始时，会发生如下情况：

1. Google Test创建一个QueueTest对象（我们把它叫做t1）。
2. t1.SetUp()初始化t1。
3. 第一个测试（IsEmptyInitiallly）在t1上运行。
4. 测试完成后，t1.TearDown()进行一些清理工作。
5. t1被析构。
6. 以上步骤在另一个QueueTest对象上重复进行，这回会运行DequeueWorks测试。

有效平台：Linux、Windows、Mac。

注意：当一个测试对象被构造时，Google Test会自动地保存所有的Google Test变量标识，对象析构后进行恢复。

调用测试

TEST()和TEST_F()向Google Test隐式注册它们的测试。因此，与很多其他的C++测试框架不同，你不需要为了运行你定义的测试而将它们全部再列出来一次。

在定义好测试后，你可以通过RUN_ALL_TESTS()来运行它们，如果所有测试成功，该函数返回0，否则会返回1.注意RUN_ALL_TESTS()会运行你链接到的所有测试——它们可以来自不同的测试案例，甚至是来自不同的文件。

当被调用时，RUN_ALL_TESTS()宏会：

1. 保存所有的Google Test标志。
2. 为一个侧测试创建测试固件对象。
3. 调用SetUp()初始化它。
4. 在固件对象上运行测试。
5. 调用TearDown()清理固件。
6. 删除固件。
7. 恢复所有Google Test标志的状态。
8. 重复上诉步骤，直到所有测试完成。

此外，如果第二步时，测试固件的构造函数产生一个致命错误，继续执行3至5部显然没有必要，所以它们会被跳过。与之相似，如果第3部产生致命错误，第4部也会被跳过。

重要：你不能忽略掉RUN_ALL_TESTS()的返回值，否则gcc会报一个编译错误。这样设计的理由是自动化测试服务会根据测试退出返回码来 决定一个测试是否通过，而不是根据其stdout/stderr输出；因此你的main()函数必须返回RUN_ALL_TESTS()的值。

而且，你应该只调用RUN_ALL_TESTS()一次。多次调用该函数会与Google Test的一些高阶特性（如线程安全死亡测试thread-safe death tests）冲突，因而是不被支持的。

有效平台：Linux、Windows、Mac。

编写main()函数

你可以从下面这个样板开始:

Cpp代码

1. #include "this/package/foo.h"
2. #include <gtest/gtest.h>
3. namespace {   
4. // 测试Foo类的测试固件
5. class FooTest : public testing::Test {   
6. protected:   
7. // You can remove any or all of the following functions if its body
8. // is empty.
9.    FooTest() {   
10. // You can do set-up work for each test here.
11.    }   
12. virtual ~FooTest() {   
13. // You can do clean-up work that doesn't throw exceptions here.
14.    }   
15. // If the constructor and destructor are not enough for setting up
16. // and cleaning up each test, you can define the following methods:
17. virtual void SetUp() {   
18. // Code here will be called immediately after the constructor (right
19. // before each test).
20.    }   
21. virtual void TearDown() {   
22. // Code here will be called immediately after each test (right
23. // before the destructor).
24.    }   
25. // Objects declared here can be used by all tests in the test case for Foo.
26. };   
27. 
    
28. // Tests that the Foo::Bar() method does Abc.
29. TEST_F(FooTest, MethodBarDoesAbc) {   
30. const string input_filepath = "this/package/testdata/myinputfile.dat";   
31. const string output_filepath = "this/package/testdata/myoutputfile.dat";   
32.    Foo f;   
33.    EXPECT_EQ(0, f.Bar(input_filepath, output_filepath));   
34. }   
35. 
    
36. // Tests that Foo does Xyz.
37. TEST_F(FooTest, DoesXyz) {   
38. // Exercises the Xyz feature of Foo.
39. }   
40. }   // namespace
41. 
    
42. int main(int argc, char **argv) {   
43. testing::InitGoogleTest(&argc, argv);   
44. return RUN_ALL_TESTS();   
45. }  

#include "this/package/foo.h"
#include <gtest/gtest.h>
namespace {
// 测试Foo类的测试固件
class FooTest : public testing::Test {
protected:
  // You can remove any or all of the following functions if its body
  // is empty.
  FooTest() {
    // You can do set-up work for each test here.
  }
  virtual ~FooTest() {
    // You can do clean-up work that doesn't throw exceptions here.
  }
  // If the constructor and destructor are not enough for setting up
  // and cleaning up each test, you can define the following methods:
  virtual void SetUp() {
    // Code here will be called immediately after the constructor (right
    // before each test).
  }
  virtual void TearDown() {
    // Code here will be called immediately after each test (right
    // before the destructor).
  }
  // Objects declared here can be used by all tests in the test case for Foo.
};

// Tests that the Foo::Bar() method does Abc.
TEST_F(FooTest, MethodBarDoesAbc) {
  const string input_filepath = "this/package/testdata/myinputfile.dat";
  const string output_filepath = "this/package/testdata/myoutputfile.dat";
  Foo f;
  EXPECT_EQ(0, f.Bar(input_filepath, output_filepath));
}

// Tests that Foo does Xyz.
TEST_F(FooTest, DoesXyz) {
  // Exercises the Xyz feature of Foo.
}
}  // namespace

int main(int argc, char **argv) {
  testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}

testing::InitGoogleTest()函数负责解析命令行传入的Google Test标志，并删除所有它可以处理的标志。这使得用户可以通过各种不同的标志控制一个测试程序的行为。关于这一点我们会在GTestAdvanced中 讲到。你必须在调用RUN_ALL_TESTS()之前调用该函数，否则就无法正确地初始化标示。

在Windows上InitGoogleTest()可以支持宽字符串，所以它也可以被用在以UNICODE模式编译的程序中。

进阶阅读

恭喜你！你已经学到了一些Google Test基础。你可以从编写和运行几个Google Test测试开始，再阅读一下GoogleTestSamples，或是继续研究GoogleTestAdvancedGuide，其中描述了很多更有用的Google Test特性。

已知局限

Google Test被设计为线程安全的。但是，我们还没有时间在各种平台上实现同步原语（synchronization primitives）。因此，目前从两个线程同时使用Google Test断言是不安全的。由于通常断言是在主线程中完成的，因此在大多数测试中这都不算问题。如果你愿意帮忙，你可以试着在gtest-port.h中实 现必要的同步原语。

Introduction

This article illustrates a snippet that permits to add color to console messages.

Background

Well, does it really need any comments?

Using the code

This sample shows how to use the library:

#include "ConsoleColor.h"


std::cout << green << "This text is written in green" 
          << white << std::endl;
std::cout << color(FOREGROUND_RED|FOREGROUND_GREEN) 
          << "This text has a really exiting color !" 
          << white << std::endl;

Now here is the "library":

Collapse

// ConsoleColor.h


#pragma once
#include <iostream>

#include <windows.h>


inline std::ostream& blue(std::ostream &s)
{
    HANDLE hStdout = GetStdHandle(STD_OUTPUT_HANDLE); 
    SetConsoleTextAttribute(hStdout, FOREGROUND_BLUE
              |FOREGROUND_GREEN|FOREGROUND_INTENSITY);
    return s;
}

inline std::ostream& red(std::ostream &s)
{
    HANDLE hStdout = GetStdHandle(STD_OUTPUT_HANDLE); 
    SetConsoleTextAttribute(hStdout, 
                FOREGROUND_RED|FOREGROUND_INTENSITY);
    return s;
}

inline std::ostream& green(std::ostream &s)
{
    HANDLE hStdout = GetStdHandle(STD_OUTPUT_HANDLE); 
    SetConsoleTextAttribute(hStdout, 
              FOREGROUND_GREEN|FOREGROUND_INTENSITY);
    return s;
}

inline std::ostream& yellow(std::ostream &s)
{
    HANDLE hStdout = GetStdHandle(STD_OUTPUT_HANDLE); 
    SetConsoleTextAttribute(hStdout, 
         FOREGROUND_GREEN|FOREGROUND_RED|FOREGROUND_INTENSITY);
    return s;
}

inline std::ostream& white(std::ostream &s)
{
    HANDLE hStdout = GetStdHandle(STD_OUTPUT_HANDLE); 
    SetConsoleTextAttribute(hStdout, 
       FOREGROUND_RED|FOREGROUND_GREEN|FOREGROUND_BLUE);
    return s;
}

struct color {
    color(WORD attribute):m_color(attribute){};
    WORD m_color;
};

template <class _Elem, class _Traits>
std::basic_ostream<_Elem,_Traits>& 
      operator<<(std::basic_ostream<_Elem,_Traits>& i, color& c)
{
    HANDLE hStdout=GetStdHandle(STD_OUTPUT_HANDLE); 
    SetConsoleTextAttribute(hStdout,c.m_color);
    return i;
}

// Copyleft Vincent Godin

采用tcp连接发送数据时,如果发送的数据的size是0,那么接收端会提示"找不到指定文件"

广播出去的包服务端自己也会收到一份，需要过滤(可以通过检测IP)，麻烦，貌似对效率有一点小小的影响，更好的方法是客户端和服务端使用不同的端口。
如服务端监听67端口，客户端监听68端口，服务端广播的包是发到67端口的，故监听68端口就不会收到自己发的广播包了^_^

项目：属性：配置属性：调试：命令参数

建议预处理器中加入宏BOOST_ALL_NO_LIB避免一些问题

Google Talk library – libjingle 测试笔记

如何开始使用boost的跨平台thread库(Windows)

  #define HANDLE_WM_CREATE(hwnd, wParam, lParam, fn) \
  ((fn)((hwnd), (LPCREATESTRUCT)(lParam)) ? 0L : (LRESULT)-1L)


当我们写下下面的代码时：
 HANDLE_MSG(hWnd, WM_CREATE, pWindow->OnCreate);

根据第一条宏定义会转化为：
case (WM_CREATE) : return HANDLE_WM_CREATE(((hwnd), (wParam), (lParam), (pWindow->OnCreate))


接下来使用第二条宏定义来替换，就成这样的了：
case (WM_CREATE) : return pWindow->OnCreate((hwnd), (LPCREATESTRUCT)(lParam)) ? 0L : (LRESULT)-1L)



忘了提醒了^_^，##的作用是将两个字符串连接起来

Answer/Solution:A blocking operation was interrupted by a call to WSACancelBlockingCall. An asynchronous signal (such as SIGINT or SIGQUIT) was caught by the process during the execution of an interruptible function. If the signal handler performs a normal return, the interrupted function call will seem to have returned the error condition.

Developer suggestions: You need to be prepared to handle this error on any functions that reference blocking sockets, or any calls to blocking functions, if you allow the user to cancel a blocking call. Whether to handle it as a fatal error or non-fatal error depends on the application and the context, so it's up to you to decide.