精品熟女少妇av免费久久,亚洲va国产va天堂va久久,久久综合香蕉国产蜜臀AV

eXile — Mon, 16 Nov 2009 05:57:00 GMT

使用��指针是C++中常用的��理内存的方式。关于智能指针的设计�Q�各路C++高手也是各展��通�?br>
�?994�q? Greg Colvin向C++标准委员会提��Z��自己设计的智能指针：auto_ptr和counted_ptr。auto_ptr实现基本的RAII��理�Q�不可复�Ӟ��counted_ptr采用引用计数实现了一个可复制的智能指针。两者用于不同的场合�?br> 但是标准委员会最�l�只通过了auto_ptr�Q��ƈ且对auto_ptr加入了一个古怪的“所有权转移”语义。后来auto_ptr和counted_ptr�q�入了Boost C++ 库，改名为scoped_ptr和shared_ptr�?br>
std::auto_ptr只所以设计�ؓ可拷贝的�Q�也许是��Z��以下考虑�Q�比如下例函敎ͼ�

void f1(object* ptr);
object* f2();

f1中的参数所指向的对象应该由谁来删除呢？调用者还是被调用者？如果不看�E�序文档的话�Q�无法知道这一炏V��f2函数也存在同��L��问题�?br>
用auto_ptr可以消除�q�种歧义性：

void f1(auto_ptr<object> ptr);
auto_ptr<object> f2();

      ��管如此�Q�auto_ptr�?#8220;所有权转移”语义�q�是会带来副作用�Q�因��Z��修改原值的帔R��拯��q�背了一般的设计原则�Q�它也许会在你意想不到的情况下就把对象�{�U�M��。它也不能用于标准容器中�?br>   所以auto_ptr在新的标准库已经不再推荐使用。取而代之的是unique_ptr。unique_ptr与auto_ptr�c�M��Q�但限制了auto_ptr的拷贝行为。同�Ӟ��像上面�D的例子一��P��unique_ptr可以作�ؓ函数的参数和�q�回��g��用。这是因为C++增加了一个新的特征：叛_��引用�?br>
   shared_ptr也进入了标准库。对于引用计数的��指针而言�Q��@环引用是一个大问题。标准库为此把shared_ptr定义为强引用指针�Q�它�q�实��C��一个弱引用指针weak_ptr。显�Ӟ��标准库�ƈ没有从根本上解决循环引用的问题，它把�q�个问题交给了程序员。在一个简单的�pȝ��中，你可以区分��用shared_ptr和weak_ptr�Q�以此来避免出现循环引用。但是在一个大的对象系�l�中�Q�有时还是容易出错。��@环引用的问题�Q�严重减�׃��shared_ptr的可用性�?br>
   那么能不能自动检��是否出现��@环引用呢�Q�事实上�Q�对于shared_ptr�q�种使用非��R入式�{�略实现的智能指针，是很隑֮�现自动检��的。但是如果采用��R入式设计�Q�我们可以引入一些接口，来解册��个问题。��@环引用的��，实际上是图论中的回�\��问题�?br>
      本文�?a style="FONT-SIZE: 12pt" title="eXile" href="http://www.shnenglu.com/eXile/">eXile 原创�Q��{载请表明原脓地址�?nbsp;http://www.shnenglu.com/eXile/�?/p>

eXile 2009-11-16 13:57 发表评论

说说C++��指针(1): 关于shared_ptr

eXile — Mon, 02 Nov 2009 09:38:00 GMT

   shared_ptr是新的标准库的一个主要成员，作�ؓ一个非嵌入式的��指针�Q�其设计可谓已经是绞��脑汁。当�Ӟ��q�有很多人对它提��Z��不满。没有完��的设计�Q�只有合适的设计�?br>
1. shared_ptr最大的特点是接口的��单性与实现的灵�z�L��?br>    对于shared_ptr,object的内存管理是可定制的�Q�甚臛_��以定制引用计数结点的内存分配�Q�以满��对内存有�Ҏ��要求的情��c��而这一切，都被Object的实现者隐藏�v来，使用Object的客��L��是不用关心的。这和以前标准库的组件实现策略有些不同。比如说, vector和vector�Q�由于内存分配策略的不同�Q�而变成类型的不同�Q�造成接口的改变�?/span>�q�一点在shared_ptr的设计时被避免了�Q�当然以一定的性能代�h。shared_ptr作�ؓC++面向对象设计的一个重要组�Ӟ��接口的简单性是很重要的�Q�必��要�?/span>接口和实现的分离。与此相似的�q�有tr1::function的设计�?br>
2.在同一体系中，各种�c�d��的智能指针可以互相�{换�?br>
   如下例：

struct Object : InterfaceA, InterfaceB {
MemberA memberA;
};

shared_ptr<Object> obj(new Object);
shared_ptr<InterfaceA> a = obj;
shared_ptr<InterfaceB> b = obj;
shared_ptr<Object> p = static_pointer_cast<Object>(b);
shared_ptr> p2 = obj;

甚至�q�可以取得数据成员的��指针�Q?br>

shared_ptr<Object> obj(new Object);
shared_ptr<MemberA> memberA(obj, &obj->memberA);

再来说说shared_ptr的缺炏V�?br>
1.对于使用引用计数的智能指针来��_��必须要小心出现��@环引用�?br> 在重度��?/span>shared_ptr的系�l�中�Q�你必须一开始就明确�c�M��cȝ��关系�Q�以军_��哪里使用shared_ptr�Q�哪里��?/span>weak_ptr�Q�否则就会出现内存泄霌Ӏ��?span style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Simsun; WHITE-SPACE: normal; ORPHANS: 2; LETTER-SPACING: normal; COLOR: #000000; WORD-SPACING: 0px" class=Apple-style-span>shared_ptr的接�?/span>转换的灵�z�L��，也很�Ҏ��D��指针被滥用�?/span>内存自动��理的问题�ƈ没有得到解决�Q�它只是被�{�U�M��?br>
2.shared_ptr使用非嵌入式设计�Q�这样可以��用于基本�c�d��Q�比�?shared_ptr。但是根据个人经验，�q�种情况在很��用。大部分情况�q�是使用自己设计的类。这有一个问题，��是没有很方便的办法实现this指针�?/span>��指针的�{换。标准库中提供了enable_shared_from_this�c�L��解决�q�个问题。但�q?/span>已经使所谓的非嵌入式设计徒有虚名。而假如一开始采�?span style="WIDOWS: 2; TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Simsun; WHITE-SPACE: normal; ORPHANS: 2; LETTER-SPACING: normal; COLOR: #000000; WORD-SPACING: 0px" class=Apple-style-span>嵌入式设计的话，则在性能代�h和多�U�程设计斚w��h��更大的灵�z�L��?/span>

eXile 2009-11-02 17:38 发表评论

最��单的foreach实现(VC & GCC)

eXile — Thu, 07 May 2009 17:25:00 GMT

摘要: 对于VC 和GCC 分别用最��单方法实��C��foreach遍历�?nbsp; 阅读全文

eXile 2009-05-08 01:25 发表评论

[T] 利用QT�q�行web与本地�؜合应用开�?

eXile — Mon, 09 Mar 2009 08:41:00 GMT

摘要: Qt提供了本�?C++对象与JavaScript的无�~�集成，是进行本��C��web混合应用开发的理想�q�_��?nbsp; 阅读全文

eXile 2009-03-09 16:41 发表评论

一个小疑问�Q�C++头文件中的静态全局变量

eXile — Fri, 09 Jan 2009 03:42:00 GMT

一般来��_��静态全局变量只应该定义在实现文�g中，但有时由于一些特�D�的目的�Q�也可能定义在头文�g中。比如在有些标准库的实现中，��q��q�种�Ҏ��来初始化标准��cin, cout�Q�或者在在tr1库中�Q�也用这�U�方法来定义占位�W�。每一个包含该头文件的实现文�g中都拥有该变量的一份拷贝，�q�些变量攑֜��q�行体的data�D�|��者bss�D�c�?br> 比如下面�q�个变量定义在一个头文�g中：

static int data[1024*1024];

我把�q�个文�g同时包含在几个cpp文�g中，按我的理解，�q�个�E�序占用的内存应该显著增大，但是�Q�从实际�q�行�l�果来看�Q��ƈ没有变化�Q�生成的exe文�g大小也没有变化，�q�是因�ؓ延迟加蝲呢，�q�是被编译器优化掉了�Q�有没有明白的达��释一下�?br>

eXile 2009-01-09 11:42 发表评论

eXile — Sat, 03 Jan 2009 17:32:00 GMT

摘要: 聊天室是一�U�典型的�|�络应用�Q�这个程序演�C�Z��ICE框架的基本结构�?nbsp; 阅读全文

eXile 2009-01-04 01:32 发表评论

利用scons�~�译Qt应用

eXile — Tue, 21 Oct 2008 15:48:00 GMT

摘要: 一般推荐qmake来编译Qt应用�E�序, qmake用�v来也很简单，但是用scons更简�? 更灵�z�R�?nbsp; 阅读全文

eXile 2008-10-21 23:48 发表评论

Google C++ Testing Framework Primer(zt)

eXile — Mon, 21 Jul 2008 03:35:00 GMT

Google C++ Testing Framework Primer

��译�Q?a target="_blank">Ray Li (ray.leex@gmail.com)
修改日期�Q?008�q?�?�?br>原文参见�Q?a >http://code.google.com/p/googletest/wiki/GoogleTestPrimer

译文地址�Q�http://www.javaeye.com/topic/212024

Introduction�Q��ؓ什么需�?/strong>Google C++ ��试框架�Q?/strong>

Google C++ ��试框架帮助你更好地�~�写C++��试�?

无论你是在Linux�Q�Windows�Q�还是Mac环境下工作，只要你编写C++代码�Q?span class="hilite1">Google ��试框架都可以帮上忙�?

那么�Q�哪些因素才能构成一个好的测试？以及�Q?span class="hilite1">Google C++ ��试框架怎样满��q�些因素�Q�我们相信：

��试应该�?em>独立�?em>可重�?/em>的。因为其他测试成功或��p�|而导致我们要对自��q��试�q�行debug是非常痛苦的�?span class="hilite1">Google C++ ��试框架通过��每个测试在不同的对象中�q�行�Q��得测试分��d��来。当一个测试失败时�Q?span class="hilite1">Google C++ ��试框架允许你独立运行它以进行快速除错�?

��试应该能够被很好地�l�织�Q��ƈ反映被测代码的结构�?span class="hilite1">Google C++ ��试框架��测试组�l�成��试案例�Q�案例中的测试可以共享数据和�E�序分支。这样一�U�通用模式能够很容易��L识，使得我们的测试容易维护。当开发�h员在��目之间转换�Q�开始在一个新的代码基上开始工作时�Q�这�U�一致性格外有用�?

��试应该�?em>可移�?/em>�?em>可重�?/em>的。开源社区有很多�q�_��独立的代码，它们的测试也应该是��^台独立的。除开一些特�D�情况，Google C++ ��试框架�q�行在不同的操作�pȝ��上、与不同的编译器�Q�gcc、icc、MSVC�Q�搭配，Google C++ ��试框架的测试很�Ҏ��与不同的配置一起工作�?

当测试失败时�Q�应该提供尽可能多的、关于问题的信息�?span class="hilite1">Google C++ ��试框架在第一个测试失败时不会停下来。相反，它只是将当前��试停止�Q�然后��l�接下来的测试。你也可以设�|�对一些非致命的错误进行报告，�q�接着�q�行当前的测试。这��P��你就可以在一��?#8220;�q�行-�~�辑-�~�译”循环中检查到�q�修复多个bug�?

��试框架应该能将��试�~�写人员从一些环境维护的工作中解攑և�来，使他们能够集中精力于��试�?em>内容�?span class="hilite1">Google C++ ��试框架自动记录下所有定义好的测试，不需要用户通过列�D来指明哪些测试需要运行�?

��试应该快�?/em>。��?span class="hilite1">Google C++ ��试框架�Q�你可以重用多个��试的共享资源，一�ơ性完成设�|?解除讄��Q�而不用��一个测试去依赖另一��试�?/li>

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

Note�Q�本文偶��会�?#8220;Google Test”来代�?#8220;Google C++ ��试框架”�?

基本概念

使用Google Test�Ӟ��你是从编�?em>断言开始的�Q�而断�a�是一些检查条件是否�ؓ真的语句。一个断�a�的结果可能是成功、非致命��p�|�Q�或者致命失败。如果一个致命失败出玎ͼ�他会�l�束当前的函敎ͼ�否则�Q�程序��l�正常运行�?

��试使用断言来验证被��代码的行�ؓ。如果一个测试崩溃或是出��C��个失败的断言�Q�那么，该测�?em>��p�|�Q�否则该��试成功�?

一个测试案例（test case�Q�包含了一个或多个��试。你应该��自��q��试分别归类到测试案例中�Q�以反映被测代码的结构。当��试案例中的多个��试需要共享通用对象和子�E�序�Ӟ��你可以把他们攑ֈ�一个测试固�Ӟ��test fixture�Q�类中�?

一�?em>��试�E�序可以包含多个��试案例�?

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

断言

Google Test中的断言是一些与函数调用�怼�的宏。要��试一个类或函敎ͼ�我们需要对其行为做出断�a�。当一个断�a��p�|�Ӟ��Google Test会在屏幕上输��代码所在的源文件及其所在的位置行号�Q�以及错误信息。也可以在编写断�a��Ӟ��提供一个自定义的错误信息，�q�个信息在失败时会被附加�?span class="hilite1">Google Test的错误信息之后�?

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

因�ؓ��p�|的ASSERT_*断言会立��M��当前的函数返回，可能会蟩�q�其后的一些的清洁代码�Q�这样也�怼��D��I�间泄漏。根据泄漏本�w�的特质�Q�这�U�情�? 也许值得修复�Q�也可能不值得我们兛_��——所以，如果你得到断�a�错误的同�Ӟ��q�得��C��一个堆��查的错误�Q�记住上面我们所说的�q�一炏V�?

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

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;

}

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; }

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

基本断言

下面�q�些断言实现了基本的true/false条�g��试�?

致命断言 非致命断�a� 验证条�g

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

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

��C��Q�当它们��p�|�Ӟ��ASSERT_*产生一个致命失败�ƈ从当前函数返回，而EXCEPT_*产生一个非致命��p�|�Q�允许函数��l�运行。在两种情况下，一个断�a��p�|都意味着它所包含的测试失败�?

有效�q�_��Q�Linux、Windows、Mac�?

二进制比�?/strong>

本节描述了比较两个值的一些断�a��?

致命断言 非致命断�a� 验证条�g

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

在出现失败事件时�Q?span class="hilite1">Google Test会将两个��|��Val1�?em>Val2�Q�都打印出来。在ASSERT_EQ*和EXCEPT_EQ*断言�Q�以及我们随后介�l�类似的断言�Q�中�Q�你应该把你希望��试的表辑ּ�攑֜�actual�Q�实际��|��的位�|�上�Q�将其期望值放�?em>expected�Q�期望��|��的位�|�上�Q�因�?span class="hilite1">Google Test的测试消息�ؓ�q�种惯例做了一些优化�?

参数值必��L��可通过断言的比较操作符�q�行比较的，否则你会得到一个编译错误。参数��D��必须支持<<操作�W�来��D��入到ostream中。所有的C++内置�c�d��都支持这一炏V�?

�q�些断言可以用于用户自定义的型别�Q�但你必��重载相应的比较操作�W�（�?=�?lt;�{�）。如果定义有相应的操作符�Q�推荐��用ASSERT_*()宏，因�ؓ它们不仅会输出比较的�l�果�Q�还会输��Z��个比较对象�?

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

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

本节中介�l�的宏都可以处理�H�字�W�串对象和宽字符串对象（string和wstring�Q��?

有效�q�_��Q�Linux、Windows、Mac�?

字符串比�?/strong>

该组断言用于比较两个C字符丌Ӏ�如果你惌��比较两个string对象�Q�相应地使用EXPECT_EQ、EXPECT_NE�{�断�a��?

致命断言 非致命断�a� 验证条�g

ASSERT_STREQ(expected_str, actual_str); EXPECT_STREQ(expected_str, actual_str); 两个C字符串有相同的内�?/td>

ASSERT_STRNE(str1, str2); EXPECT_STRNE(str1, str2); 两个C字符串有不同的内�?/td>

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

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

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

*STREQ*�?STRNE*也接受宽字符�Ԍ��wchar_t*�Q�。如果两个宽字符串比较失败，它们的��g��做�ؓUTF-8�H�字�W�串被输出�?

一个NULL�I�指针和一个空字符串会被认为是不一�?/em>的�?

有效�q�_��Q�Linux、Windows、Mac�?

参见�Q�更多的字符串比较的技巧（如子字符丌Ӏ�前�~�和正则表辑ּ�匚w��Q�，请参见[Advanced Guide Advanced Google Test Guide]�?

��单的��试

要创��Z��个测试：

使用TEST�Q�）宏来定义和命名一个测试函敎ͼ�它们是一些没有返回值的普通C++函数�?

在这个函��C��Q�与你想要包含的其它��M��有效C++代码一��P��使用Google Test提供的各�U�断�a�来进行检查�?

��试的结果由其中的断�a�军_��Q�如果测试中的�Q意断�a��p�|�Q�无论是致命�q�是非致命）�Q�或者测试崩溃，那么整个��试��失败了。否则，��试通过�?nbsp;

TEST(test_case_name, test_name) {

... test body ...

}

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

TEST�Q�）的参数是从概括到�Ҏ��的�?em>�W�一�?/em>参数是测试案例的名称�Q?em>�W�二�?/em>参数是测试案例中的测试的名称。记住，一个测试案例可以包含�Q意数量的独立��试。一个测试的全称包括了包含它的测试案例名�U�ͼ�及其独立的名�U�。不同测试案例中的独立测试可以有相同的名�U��?

举例来说�Q�让我们看一个简单的整数函数�Q?

int Factorial(int n); // �q�回n的阶�?/span>

int Factorial(int n); // �q�回n的阶�?/pre>

�q�个函数的测试案例应该看��h��像是�Q?

// ��试0的阶�?/span>

TEST(FactorialTest, HandlesZeroInput) {

  EXPECT_EQ(1, Factorial(0));

}

// ��试正数的阶�?/span>

TEST(FactorialTest, HandlesPositiveInput) {

  EXPECT_EQ(1, Factorial(1));

  EXPECT_EQ(2, Factorial(2));

  EXPECT_EQ(6, Factorial(3));

  EXPECT_EQ(40320, Factorial(8));

}

// ��试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�Ҏ��试案例来分�l�收集测试结果，因此�Q�逻辑相关的测试应该在同一��试案例中；换句话说�Q�它们的TEST�Q�）的第一个参数应该是一��L��。在上面的例子中�Q�我们有两个��试�Q�HandlesZeroInput和HandlesPostiveInput�Q�它们都属于同一个测试案例FactorialTest�?

有效�q�_��Q�Linux、Windows、Mac�?

��试��Z�g�Q?/strong>Test Fixtures�Q�又做测试夹兗��测试套�Ӟ��Q�在多个��试中��用同��L��数据配置

当你发现自己�~�写了两个或多个��试来操作同��L��数据�Q�你可以采用一�?em>��试��Z�g。它让你可以在多个不同的��试中重用同��L��对象配置�?

要创建测试固�Ӟ��只需�Q?

创徏一个类�l�承�?span class="hilite2">testing::Test。将其中的成员声明�ؓprotected:或是public:�Q�因为我们想要从子类中存取固件成员�?

在该�c�M��声明你计划��用的��M��对象�?

如果需要，�~�写一个默认构造函数或者SetUp()函数来�ؓ每个��试准备对象。常见错误包括将SetUp()拼写为Setup()�Q�小写了u�Q�——不要让它发生在你��n上�?

如果需要，�~�写一个析构函数或者TearDown()函数来释放你在SetUp()函数中申��L��资源。要知道什么时候应该��用构造函�?析构函数�Q�什么时候又应该使用SetUp()/TearDown()函数�Q�阅��L��们的FAQ�?

如果需要，定义你的��试所需要共享的子程序�?/li>

当我们要使用��Z�g�Ӟ��使用TEST_F()替换�?span class="hilite2">TEST()�Q�它允许我们存取��试��Z�g中的对象和子�E�序�Q?

TEST_F(test_case_name, test_name) {

... test body ...

}

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

�?span class="hilite2">TEST()一��P��W�一个参数是��试案例的名�U�ͼ�但对TEST_F()来说�Q�这个名�U�必��M��试��Z�g�cȝ��名称一些。你可能已经猜到了：_F正是指固件�?

不幸地是�Q�C++宏系�l��ƈ不允许我们创��Z��个单独的宏来处理两种�c�d��的测试。��用错误的宏会��D��~�译期的错误�?

而且�Q�你必须�?span class="hilite2">TEST_F()中��用它之前�Q�定义好�q�个��试��Z�g�c�R��否则，你会得到�~�译器的报错�Q?#8220;virtual outside class declaration”�?

对于TEST_F()中定义的每个��试�Q?span class="hilite1">Google Test��会�Q?

在运行时创徏一�?em>全新的测试固�?

马上通过SetUp()初始化它�Q?

�q�行��试

调用TearDown()来进行清理工�?

删除��试��Z�g。注意，同一��试案例中，不同的测试拥有不同的��试��Z�g�?span class="hilite1">Google Test在创��Z��一个测试固件前��L��会对现有��Z�g�q�行删除�?span class="hilite1">Google Test不会对多个测试重用一个测试固件。测试对��试��Z�g的改动�ƈ不会影响到其他测试�?/li>

例如�Q�让我们��Z��个名为Queue的FIFO队列�cȝ��写测试，该类的接口如下：

template <typename E> // E为元素类�?/span>

class Queue {

public:

  Queue();

  void Enqueue(const E& element);

  E* Dequeue(); // �q�回 NULL 如果队列为空.

  size_t size() const;

  ...

};

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

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

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_;

};

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

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

接下来我们��?span class="hilite2">TEST_F()和这个固件来�~�写��试�?

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;

}

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; }

上面�q�段代码既��用了ASSERT_*断言�Q�又使用了EXPECT_*断言。经验上�Ԍ��如果你想要断�a��p�|后，��试能够�l�箋�q�行以显�C�更多的错误 �Ӟ��你应该��用EXPECT_*断言�Q��用ASSERT_*如果该断�a��p�|后��l�往下执行毫无意义。例如，Dequeue��试中的�W�二个断�a��? ASSERT_TURE(n!= NULL)�Q�因为我们随后会n指针解引用，如果n指针为空的话�Q�会��D��一个段错误�?

当这些测试开始时�Q�会发生如下情况�Q?

Google Test创徏一个QueueTest对象�Q�我们把它叫做t1�Q��?

t1.SetUp()初始化t1�?

�W�一个测试（IsEmptyInitiallly�Q�在t1上运行�?

��试完成后，t1.TearDown()�q�行一些清理工作�?

t1被析构�?

以上步骤在另一个QueueTest对象上重复进行，�q�回会运行DequeueWorks��试�?/li>

有效�q�_��Q�Linux、Windows、Mac�?

注意�Q�当一个测试对象被构造时�Q?span class="hilite1">Google Test会自动地保存所有的Google Test变量标识�Q�对象析构后�q�行恢复�?

调用��试

TEST()�?span class="hilite2">TEST_F()�?span class="hilite1">Google Test隐式注册它们的测试。因此，与很多其他的C++��试框架不同�Q�你不需要�ؓ了运行你定义的测试而将它们全部再列出来一�ơ�?

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

当被调用�Ӟ��RUN_ALL_TESTS()宏会�Q?

保存所有的Google Test标志�?

��Z��个侧��试创徏��试��Z�g对象�?

调用SetUp()初始化它�?

在固件对象上�q�行��试�?

调用TearDown()清理��Z�g�?

删除��Z�g�?

恢复所�?span class="hilite1">Google Test标志的状态�?

重复上诉步骤�Q�直到所有测试完成�?/li>

此外�Q�如果第二步�Ӟ��试��Z�g的构造函��C�生一个致命错误，�l�箋执行3�?部显然没有必要，所以它们会被蟩�q�。与之相��|��如果�W?部��生致命错误，�W?部也会被跌��?

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

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

有效�q�_��Q�Linux、Windows、Mac�?

�~�写main()函数

你可以从下面�q�个��h��开�?

#include "this/package/foo.h"

#include test/gtest.h>

namespace {

// ��试Foo�cȝ��试��Z�g

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();

}

#include "this/package/foo.h" #include test/gtest.h> namespace { // ��试Foo�cȝ��试��Z�g 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()函数负责解析命��o行传入的Google Test标志�Q��ƈ删除所有它可以处理的标志。这使得用户可以通过各种不同的标志控制一个测试程序的行�ؓ。关于这一�Ҏ��们会在GTestAdvanced中讲到。你必须在调用RUN_ALL_TESTS()之前调用该函敎ͼ�否则��无法正��地初始化标�C��?

在Windows上InitGoogleTest()可以支持宽字�W�串�Q�所以它也可以被用在以UNICODE模式�~�译的程序中�?

�q�阶阅读

恭喜你！你已�l�学��C��一�?span class="hilite1">Google Test基础。你可以从编写和�q�行几个Google Test��试开始，再阅��M��?a >GoogleTestSamples�Q�或是��l�研�I?a >GoogleTestAdvancedGuide�Q�其中描�q�C��很多更有用的Google Test�Ҏ��?

已知局�?/strong>

Google Test被设计�ؓ�U�程安全的。但是，我们�q�没有时间在各种�q�_��上实现同步原语（synchronization primitives�Q�。因此，目前从两个线�E�同时��?span class="hilite1">Google Test断言是不安全的。由于通常断言是在�ȝ��E�中完成的，因此在大多数��试中这都不��问题。如果你愿意帮忙�Q�你可以试着在gtest-port.h中实现必要的同步原语�?/p>

eXile 2008-07-21 11:35 发表评论

eXile — Tue, 01 Jul 2008 07:24:00 GMT
   原文地址�Q?nbsp;http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Displaying_Hidden_Details_in_this_Guide#Naming

   ��h��的C++代码风格与网上广为流传的林锐风格有很大不同，不过正如文中所�a��Q�重要的是保持一致。它�q�说��Z��每一�U�风格的优缺点，�q�里只说几个比较有意思的�?br>
   1�Q�关于空行：
   基本原则�Q��一个屏�q�能容纳更多的代码（昄��Q�这是K&R风格的拥��?

   2) 关于引用参数�Q?br>   所有的引用前加 const, 如下列：
   void f(const Object& in, Object& out); // bad
   void f(const Object& in, Object* out); // good

   以上两点倒是和Qt�怼��Q�还有一个相似的地方是：��量不要�?unsigned�?br>
   3�Q�关于全局变量�Q?br>   ��止使用�c�d��局变量�Q�可以��用一些内�|�类型的全局变量。（��Z��避免初始化顺序问题）�?br>
   4�Q�不提倡的C++�Ҏ��：
   ��量不要使用多重�l�承�Q?br>    ��量不要使用操作�W�重载；
   ��量不要使用函数重蝲�Q?br>    不要使用函数�~�省参数�Q?br>    不要使用异常�Q?br>    不要使用RTTI�Q?br>   内置的整性类型只使用int.(64位可使用int64_t, 指针兼容可��用intptr_t或ptrdiff_t).

   具体的理由和更多的风格参见原文�?br>   另外�Q�还可以和Java风格做个�Ҏ��Q?br>   http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

eXile 2008-07-01 15:24 发表评论

eXile — Wed, 28 May 2008 13:00:00 GMT
     摘要: 利用boost::asio实现一个简单的服务器框�?nbsp; 阅读全文

eXile 2008-05-28 21:00 发表评论

boost::asio�C�Z��HTTP Server�c�d��

eXile — Tue, 06 May 2008 16:50:00 GMT

eXile 2008-05-07 00:50 发表评论

两个��y的开源解析库

eXile — Wed, 16 Apr 2008 05:49:00 GMT
　�q�两个库都是�Q�语�a�实现的轻量��开源库�Q�具有简单易用和快速高效的特点�?br>
　�Q�）Expat�Q��Q�Ｌ解析库　http://expat.sourceforge.net/
　　　��Z��Q�I��Q怺�件模型，据说是应用最�q�泛的��Q�Ｌ解析器，��Z��多的开源��Y件所采用。注意如果要支持中文�Q�必��M��用Ｕ�Q�_�u�Q�８�~�码�?br>
　�Q�）Henry Spencer's Regexp Engine �Q�正则表辑ּ�解析库　http://www.codeproject.com/KB/string/spencerregexp.aspx
　　　最初由Henry Spencer 为tcl/tk所做的正则式实�?/span>。由于它的小巧，也被一些其它的开源库所使用。据我所知，MY SQL 数据库，wxWidgets库都采用了这个实现进行正则式分析。�ؓ了保持它的简单性，作者也舍弃了一些特征，比如�?{n, m}语法�Q�以及后向引用等�?

eXile 2008-04-16 13:49 发表评论

utf8�~�码转换

eXile — Tue, 15 Apr 2008 17:26:00 GMT

     只用�?Windows �q�_��.

using std::string;
using std::vector;

inline string utf8_trans_impl(string const& from, int from_code, int to_code)
{
    int len16 = MultiByteToWideChar(from_code, 0, from.begin(), from.size(), 0, 0);
    if (len16 > 0)
    {
        vector<wchar_t> ucs2_buf(len16, 0);
        len16 = MultiByteToWideChar(from_code, 0, from.begin(), from.size(), ucs2_buf.begin(), len16);

        int len8 = WideCharToMultiByte(to_code, 0, ucs2_buf, len16, 0,  0, 0, 0);
        string result(len8, 0);
        WideCharToMultiByte(to_code, 0, ucs2_buf.begin(), len16, result.begin(),  len8, 0, 0);
        return result;
    }

       return  string();
}

inline string from_utf8(string const& from)
{
    return utf8_trans_impl( from, CP_UTF8, CP_ACP);
}

inline string to_utf8(string const& from)
{
    return utf8_trans_impl(from, CP_ACP, CP_UTF8);
}

     转蝲误��明原文地址: http://www.shnenglu.com/exile/

eXile 2008-04-16 01:26 发表评论

GCC4.3...

eXile — Thu, 13 Mar 2008 03:56:00 GMT

　　�Q��E�Q�４.�Q�发布了�Q�终于可以试试传说中的C++0x, ��管只是部分。对于新的语�a��Ҏ��，也尝试着了解了一下�?br>　　�Q�）改变最大的语言�Ҏ��就是右值引用了。花了半天去搞清楚什么是叛_��引用，对于std::move和std::forward�q�两个函��C��蒙了好长旉��。觉得这个东西似乎对一般的开发者没什么用处，除非你要开发一个��E�Q�＋库。好象标准库的容器除了basic_string外，基本上都支持了这炏V��智能指针shared_ptr也支持了叛_��引用。�ؓ了提高效率，又增加了语言的复杂性，�q�大概就是c++的语�a�哲学吧�?br>　　�Q�）可变参数模板。这个用来实现std::function�Q�std::bind及std::tuple.
　　�Q�）static_assert。这个自己实��C��个也很容易�?br>　　�Q�）decltype。就是以前的__typeof__。这�ơ只不过是扶正了�?br> 　　�Q�）模板中＞�Q�可以连着写了�?br>　　�Q�）函数模板也可以有�~�省参数了�?br>　　�Q�）。。。�?br>　　�Q�）对于标准库的一些容器算法采用了�q�行处理。看来还是要��可能多的��用标准库�?br>
　　不过我编译了一个标准的HelloWorld�Q��用iostream�Q�，Debug 版本的可执行文�g竟然�?.5M�Q�幸好Release下还没有增加太多�?br> 　　

eXile 2008-03-13 11:56 发表评论

设计Qt风格的C++API (zt)

eXile — Sun, 17 Feb 2008 16:50:00 GMT

设计Qt风格的C++API

作者Matthias Ettrich�Q�译者Googol Lee�Q�原文地址�?a >�q�里�?

在奇��（Trolltech�Q�，��Z��改进Qt的开发体验，我们做了大量的研�I�。这��文章里�Q�我打算分��n一些我们的发现�Q�以及一些我们在设计Qt4时用到的原则�Q��ƈ且展�C�如何把�q�些原则应用��C��的代码里�?

好的API的六个特�?/font>
便利陷阱
布尔参数陷阱
静态多�?/font>
命名的艺�?/font>
指针�q�是引用�Q?/font>
例子�Q�QProgressBar
如何把API设计�?/font>

设计应用�E�序接口�Q�API�Q�是很难的。这是一门和设计语言同样隄��艺术。这里可以选择太多的原则，甚至有很多原则和其他原则有矛盾�?

现在�Q�计��机�U�学教育把很大的力气攑֜��法和数据结构上�Q�而很��关注设计语�a�和框架背后的原则。这让应用程序员完全没有准备去面对越来越重要的�Q务：创造可重用的组件�?

在面向对象语�a�普及之前�Q�可重用的通用代码大部分是由库提供者写的，而不是应用程序员。在Qt的世界里�Q�这�U�状冉|��了明昄��改善。在��M��时候，用Qt�~�程��是写新的组件。一个典型的Qt应用�E�序臛_��都会有几个在�E�序中反复��用的自定义组件。一般来��_��同样的组件会成�ؓ其他应用�E�序的一部分。KDE�Q�K桌面环境�Q�走得更�q�，用许多追加的库来扩展Qt�Q�实��C��数百个附加类。（一般来��_��一个类��是一个可重用�l��g�Q�原文这里没有写清楚。）

但是�Q�一个好的，高效的C++ API是由什么组成的呢？是好�q�是坏，取决于很多因素——比如，手头的工作和特定的目标群体。好的API有很多特性，一些特性是大家都想要的�Q�而另一些则是针对特定问题域的�?

好的API的六个特�?/h2>
API是面向程序员的，用来描述提供�l�最�l�用��L��GUI是什么样子。API中的P带表�E�序员（Programmer�Q�，而不是程序（Program�Q�，用来��API是给�E�序员用的，�l��h�cȝ��E�序员用的�?

我们坚信API应该是最��化且完整的�Q�拥有清��C��单的语义�Q�直觉化�Q�容易记忆，�q�且引导人写出易�ȝ��代码�?

最��化�Q?/strong>最��化的API是指一个类��可能只拥有最��的公开成员且尽可能只拥有最��的�c�R��这个原则可以让API更简单易懂，更好讎ͼ�更容易除错，且更�Ҏ��改变�?
完整的：完整的API是指要提供所有期望的功能。这个可能与最��化原则相冲�H�。另外，如果一个成员函数属于一个不应该属于的类�Q�很多潜在的使用者都会找不到�q�个函数�?
拥有清晰且简单的语义�Q?/strong>��像其他设计工作一��P��你必��遵守最��惊奇原则（the principle of least surprise�Q�。让常见的�Q务简单易行。不常见的工作可行，但不会让用户�q�分��x��。解决特�D�问题时�Q�不要让解决�Ҏ��没有必要的过度通用。（比如�Q�Qt3中的QMimeSourceFactory可以通过调用QImageLoader来实��C��同的API。）
直觉化：��像电脑上的其他东西一��P��API必须是直觉化的。不同的�l�验和背景会��D��在判断什么是直觉而什么不是时不同的感觉。如果一个中�U�用户不��L��档就可以使用�Q�a semi-experienced user gets away without reading the documentation�Q�没懂这里的get away该怎么��译�Q�，�q�且一个程序员不懂API��可以理解羃写的代码�Q�这�U�API��是直觉化的�?
易于记忆�Q?/strong>让API易于记忆�Q��用统一且精��的命名�Ҏ��。��用可识别的模式和概念�Q��ƈ且避免羃写�?
引导易读的代码（Lead to readable code�Q�：代码一�l�写��，会读�Q��ƈ且除错和修改�Q�多�ơ。易�ȝ��代码可能会花�Ҏ��间来写，但是可以节省产品周期中的其他旉��?

最后，��C��Q�不同类型的用户会用到API的不同部分。虽然简单的实例化一个Qt�c�L��非常直觉化的�Q�让资深专家在试囑֭��c�d��之前��M��遍文档，是很合理的�?

便利陷阱

�q�是个常见的误解�Q�更好的API�Q�用更少的代码完成一件事。永�q�记住代码一�ơ写��，之后需要不断的阅读�q�理解。比如：

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

�q�比下面那样难读�Q�甚至难写）�Q?

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

布尔参数陷阱

布尔参数通常会导致不易读的代码。更�q�一步，�l�一个已�l�存在的函数加入一个布��参敎ͼ��q�常常是个错误。在Qt里，一个传�l�的例子是repaint()�Q�这个函数带有一个布��参敎ͼ�来标识是否擦除背景（默认擦除�Q�。这让代码通常写成�Q?

widget->repaint(false);

初学者很�Ҏ��把这句话理解�?#8220;别重�?#8221;�Q?

�q�样做是考虑到布��参数可以减��一个函敎ͼ�避免代码膨胀。事实上�Q�这反而增加了代码量。有多少Qt用户真的��C��了下面三行程序都是做什么的�Q?

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

一个好一些的API可能看�v来是�q�样�Q?

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

在Qt4里，我们重新设计了widget�Q��得用户不再需要不重画背景的重画widget�Q�来解决�q�个问题。Qt4原生支持双缓存，废掉了这个特性�?

�q�里�q�有一些例子：

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

一个显而易见的解决�Ҏ��是，使用枚�D�c�d��代替布尔参数。这正是我们在Qt4�?a >QString大小写敏感时的处理方法。比较：

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

静态多�?/h2>
�怼�的类应该含有�怼�的API。在必要的时候——就是说�Q�需要��用运行时多态的时候——这可以通过�l�承实现。但是多态依旧会发生在设计时期。比如，如果你用QListBox代替QComboBox�Q�或者用QSlider代替QSpinBox�Q�你会发现相似的API使这�U�替换非常容易。这��是我们所说的“静态多�?#8221;�?

静态多态也使API和程序模式更�Ҏ��记忆。作为结论，一�l�相关类使用�怼�的API�Q�有时要比给每个�c�L��供完��的单独API�Q�要好�?

�Q�译注：C++ 0x��要引入的concept�Q�就是静态多态的语法层实现。这个要比单独的函数名相似更强大且易用。）

命名的艺�?/h2>
命名�Q�大概是设计API时唯一最重要的问题了。该怎么�U�呼�q�个�c�？成员函数该叫什么？

通用的命名规�?/h3>
一些规则通常�Ҏ��有名字都是有用的。首先，��像我之前提到的�Q�别用羃写。甚臛_��明显的羃写，比如“prev”表示“previous”从长�q�看也是不划��的�Q�因为用户必��记住哪些词是羃写�?

如果API本��n不一��_��事情自然会变得很�p�糕�Q�比如， Qt3有activatePreviousWindow()和fetchPrev()。坚�?#8220;没有�~�写”的规则更�Ҏ��创徏一致的API�?

另一个重要但更加微妙的规则是�Q�在设计�cȝ��时候，必须��力保证子类命名�I�间的干净。在Qt3里，没有很好的遵守这个规则。比如，�?a >QToolButton来�D例。如果你在Qt3里，对一�?a >QToolButton调用name()、caption()、text()或者textLabel()�Q�你希望做什么呢�Q�你可以在Qt Designer里拿QToolButton试试�Q?

name属性��承自QObject�Q�表�C�Z��个对象用于除错和��试的内部名字�?
caption属性��承自QWidget�Q�表�C�窗口的标题�Q�这个标题在视觉上对QToolButton没有��M��意义�Q�因��Z��们��L��跟随父窗口而创建�?
text属性��承自QButton�Q�一般情况下是按钮上现实的文字，除非useTextLabel为真�?
textLabel�?a >QToolButton里声明，�q�且在useTextLabel为真时显�C�在按钮上�?

�׃��对可��L��的��x��Q�name在Qt4里被�U�C��objectName�Q�caption变成了windowsTitle�Q�而在QToolButton里不再有单独的textLabel属性�?

�l�类命名

标识一�l�类而不是单独给每个�c�L��个恰当的名字。比如，Qt4里所有模式感知项目的视图�c�（model-aware item view classes�Q�都拥有-View的后�~��Q?a >QListView�?a >QTableView�?a >QTreeView�Q�，�q�且对应��Z��目的类都用后缀-Widget代替�Q?a >QListWidget�?a >QTableWidget�?a >QTreeWidget�Q��?

�l�枚丄��型及其值命�?/h3>
当声明枚举时�Q�时刻记住，在C++�Q�不像Java和C#�Q�中�Q��用枚丑ր�g��需要类型信息。下面的例子演示了给枚�D��D�v个太�q�常用的名字所引�v的危宻I��

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

在最后一行，Insensitive是什么意思？一个用于命名枚丑ր�的指导思想是，在每个枚丑ր�里�Q�至��重复一个枚丄��型名中的元素�Q?

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

当枚丑ր�可以用“�?#8221;�q�接��h��当作一个标志时�Q�传�l�的做法是将“�?#8221;的结果作��Z��个int保存�Q�这不是�c�d��安全的。Qt4提供了一个模板类 QFlags来实现类型安全，其中T是个枚�D�c�d��。�ؓ了方便��用，Qt为很多标志类名提供了typedef�Q�所以你可以使用�c�d�� Qt::Alignment代替QFlags�?

��Z��方便�Q�我们给枚�D�c�d��单数的名字（�q�样表示枚�D��g��ơ只能有一个标志）�Q��?#8220;标志”则��用复数名字。比如：

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

有些情况下，“标志“�c�M��用了单数的名字。这�Ӟ��枚�D�c�M��?Flag做后�~��Q?

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

�Q�这里�ؓ啥不是把”标志“�cȝ��-Flag做后�~��Q�而是把枚丑ր�做后缀呢？感觉有点��h��……�Q?

�l�函数和参数命名

�l�函数命名的一个规则是�Q�名字要明确体现��个函数是否有副作用。在Qt3�Q�常数函�?a >QString::simplifyWhiteSpace()�q�反了这个原则，因�ؓ它返回类一�?a >QString实例�Q�而不是像名字所提示的那��P��更改了调用这个函数的实例本��n。在Qt4�Q�这个函数被重命名�ؓQString::simplified()�?

参数名是�E�序员的重要信息来源�Q�虽然在使用API�Ӟ��q�不直接展示在代码里。由于现代IDE在程序员写代码时可以自动昄��参数名（��是自动感知或者自动补全之�cȝ��功能�Q�，值得花时间给头文仉��声明的参��C��个合适的名字�Q��ƈ且在文档中也使用相同的名字�?

�l�布��D��|�函敎ͼ�Setter�Q�、提取函敎ͼ�Getter�Q�和属性命�?/h3>
�l�布��属性的讄��函数和提取函��C��个合适的名字�Q��L��非常痛苦的。提取函数应该叫做checked()�q�是isChecked()�Q�scrollBarsEnabled()�q�是areScrollBarEnabled()?

在Qt4里，我们使用下列规则命名提取函数�Q?

形容�cȝ��属性��用is-前缀。比如：

isChecked()
isDown()
isEmpty()
isMovingEnable()

另外�Q�应用到复数名词的�Ş容类属性没有前�~��Q?

scrollBarsEnabled()�Q�而不�?tt>areScrollBarsEnabled()

动词�cȝ��属性不使用前缀�Q�且不��用第三�h�U�ͼ�-s�Q�：

acceptDrops()�Q�而不�?tt>acceptsDrops()
allColumnsShowFocus()

名词�cȝ��属性，通常没有前缀�Q?

autoCompletion()�Q�而不�?tt>isAutoCompletion()
boundaryChecking()

有时�Q�没有前�~��׃��引�v误解�Q�这�U�情况��用前�~�is-�Q?

isOpenGLAvailable()�Q�而不�?tt>openGL()
isDialog()�Q�而不�?tt>dialog()

�Q�通过调用dialogue()�Ҏ��Q�正常情况下会期望返回一�?a >QDialog*的实例。）

讄��函数名字�l�承自提取函数名�Q�只是移掉了所有前�~��Q��ƈ使用set-做前�~��Q�比如：setDown()�q�有setScrollBarsEnabled()。属性的名字与提取函数相同，只是��L��了前�~��?

指针�q�是引用�Q?/h2>
传出参数的最佳选择是什么，指针�q�是引用�Q?

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

大部分C++书推荐在能用引用的地方就用引用，�q�是因�ؓ一般认为引用比指针�?#8220;安全且好�?#8221;。然而，在奇��（Trolltech�Q�，我们們֐�使用指针�Q�因��让代码更易读。比较：

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

只有�W�一行能清楚的说明，在函数调用后�Q�h、s和v��有很大几率被改动�?

例子�Q�QProgressBar

��Z��展示如何实际应用�q�些概念�Q�我们将学习Qt3中的API QProgressBar�q�和Qt4里相通的API做比较。在Qt3里：

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相当复杂�Q�且不统一。比如，仅从名字reset()�q�不能理解其作用�Q�setTotalSteps()和setProgress()是紧耦合的�?

改进API的关键，是注意到QProgressBar和Qt4�?a >QAbstractSpinBox�c�d��其子�c?a >QSpinBox�Q?a >QSlider�?a >QDial很相伹{��解��x��法？用minimum、maximum和value代替progress和totalSteps。加入alueChanged()信号。加入setRange()函数�?

之后观察progressString、percentage和indicator实际都指一个东西：在进度条上显�C�的文字。一般来说文字是癑ֈ�比信息，但是也可以��用setIndicator()设�ؓ��L��字符。下面是新的API�Q?

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

默认的文字信息是癑ֈ�比信息。文字信息可以藉由重新实现text()而改变�?

在Qt3 API中，setCenterIndicator()和setIndicatorFollowStyle()是两个媄响对齐的函数。他们可以方便的�׃��个函数实玎ͼ�setAlignment()�Q?

void setAlignment(Qt::Alignment alignment);

如果�E�序员不调用setAlignment()�Q�对齐方式基于当前的风格。对于基于Motif的风��|��文字��居中显�C�；对其他风��|��文字��靠在右辏V�?

�q�是改进后的QProgressBar API�Q?

class QProgressBar : public QWidget { ... 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); ... };

如何把API设计好（原文是How to Get APIs Right�Q�我��L��成We do APIs right……�Q?/h2>
API需要质量保证。第一个修订版不可能是正确的；你必��d��试。写些用例：看看那些使用了这些API的代码，�q��证代码是否易诅R�?

其他的技巧包括让别的人分别在有文档和没有文档的情况下�Q��用这些API�Q�或者�ؓAPI�c�d��文档�Q�包括类的概�q�和独立的函敎ͼ��?

当你卡住�Ӟ��写文档也是一�U�获得好名字的方法：仅仅是尝试把条目�Q�类�Q�函敎ͼ�枚�D��|��{�等呢个�Q�写下来�q�且使用你写的第一句话作�ؓ灉|��。如果你不能扑ֈ�一个精��的名字�Q�这常常说明�q�个条目不应该存在。如果所有前面的事情都失败了�q�且你确认这个概�늚�存在�Q�发明一个新名字。毕竟，“widget”�?“event”�?#8220;focus”�?#8220;buddy”�q�些名字��是�q�么来的�?

eXile 2008-02-18 00:50 发表评论

vector的有序化操作

eXile — Tue, 29 Jan 2008 05:13:00 GMT
　　在有些情况下�Q�需要用��C��个有序的vector。它的有序操作有三种�Q�查找，插入�Q�删除�?br>　　
　　插入实现�Q?
template <typename Container>
inline void ordered_insert(Container& c,　 typename Container::value_type const& t)
{
    c.insert(std::upper_bound(c.begin(), c.end(), t), t);
}

template <typename Container, typename Cmp>
inline void ordered_insert(Container& c,　typename Container::value_type const& t,　Cmp cmp)
{
    c.insert(std::upper_bound(c.begin(), c.end(), t, cmp), t);
}
　　
　　删除实现�Q?
template <typename Container, typename It>
inline void erase_range(Container& c, std::pair<It, It> const& r)
{
    c.erase(r.first, r.second);
}

template <typename Container>
inline void ordered_erase(Container& c, 　typename Container::value_type const& t)
{
    erase_range(c, std::equal_range(c.begin(), c.end(), t));
}

template <typename Container, typename T, typename Cmp>
inline void ordered_erase(Container& c, T const& t, Cmp cmp)
{
    erase_range(c, std::equal_range(c.begin(), c.end(), t, cmp));
}

　　查找可通过binary_search, lower_bound, upper_bound, 或者equal_range实现。如果要实现�c�M��map的关键字搜烦�Q�有一个技巧，��是用比较函数进行重载，比如学生要按学号查找�Q�则用以下定义：

struct Student
{
    int            id;
    std::string name;

    struct LessThan
    {
        bool operator() (Student const& x, Student const& y)
        {
            return x.id < y.id;
        }

        bool operator() (Student const& x, int id)
        {
            return x.id < id;
        }

        bool operator() (int id, Student const& y)
        {
            return id < y.id;
        }
    };
};

查找学号�?的学生：

std::vector students;

bool exist = std::binary_search(students.begin(), students.end(), 5, Student::LessThan());

删除学号�?的学生：

ordered_erase(students, 5, Student::LessThan());

eXile 2008-01-29 13:13 发表评论

eXile — Wed, 09 Jan 2008 02:59:00 GMT
     摘要: 自从掌握了signal/slot机制后，它已�l�变成了我在设计中一�U�必不可��的�Ҏ��Q�如何在非Ｑ�Q�环境中使用�q�种机制�Q�也是我一直在考虑的问题。目前的�q�个版本�Q�相�Ҏ��说还是比较满意的�Q�而且个�h认�ؓ它要优于Boost::signal的实现�?nbsp; 阅读全文

eXile 2008-01-09 10:59 发表评论

QT中异形窗口的�l�制

eXile — Sun, 09 Dec 2007 07:06:00 GMT

　　�q�里讨论的只是Windows�q�_��上的实现�?br>　　在Ｑ�Q�中�l�制异�Ş�H�口�Q�只要设�?windowFlag �?CustomizeWindowHint�Q�再�l�合setMask()��可以做出各�U�奇形怪状的窗口。相�Ҏ��说比较麻烦的, 是进行窗口拖动和�~�放的处理�?br>　　�?Windows SDK �?MFC　中比较容易，只要处理 WM_NCHITTEST�Q�返回相应的��试值就可以了。幸�q�的是，�Q�Ｔ中也提供了直接处理各�q�_��消息的方法，�?Windows下只需要重载winEvent�Ҏ��?br>
　　下面�l�出了示例代码：

// include

bool MyDialog::winEvent(MSG* msg, long* result)
{
    const int captionHeight = 25;
    const int frameWidth = 6;

    if (msg->message != WM_NCHITTEST) return false;

    QPoint pos = mapFromGlobal(QCursor::pos());
    int w = width();
    int h = height();

    if (QRect(frameWidth, captionHeight, w-frameWidth-frameWidth, h-captionHeight-frameWidth).contains(pos))
    {
        *result = HTCLIENT;
    }
    else if (QRect(0, 0, w, captionHeight).contains(pos))
    {
        *result = HTCAPTION;
    }
    else if (QRect(0, captionHeight, frameWidth, h-captionHeight-frameWidth).contains(pos))
    {
        *result = HTLEFT;
    }
    else if (QRect(w-frameWidth, captionHeight, frameWidth, h-captionHeight-frameWidth).contains(pos))
    {
        *result = HTRIGHT;
    }
        else if (QRect(frameWidth, h-frameWidth, w-frameWidth-frameWidth, frameWidth).contains(pos))
       {
          *result = HTBOTTOM;
       }
    else if (QRect(0, h-frameWidth, frameWidth, frameWidth).contains(pos))
    {
        *result = HTBOTTOMLEFT;
    }
    else if (QRect(w-frameWidth, h-frameWidth, frameWidth, frameWidth).contains(pos))
    {
        *result = HTBOTTOMRIGHT;
    }

    return true;
}

eXile 2007-12-09 15:06 发表评论

悬挂指针与boost::weak_ptr

eXile — Thu, 11 Oct 2007 03:49:00 GMT

　　与内存泄露相比，C++最令�h头痛的问题是内存��界�Q�而内存越界很多情况下是由于悬挂指针引��L��。　　
　　假设一个指针变量：
　　Object * ptr;
　　使用ptr�Ӟ��我们除了要判断ptr是否�?以外�Q�还要怀疑它指向的对象是否有效，是不是已�l�在别的地方被销毁了。我们希望当它指向的对象被销毁时�Q�ptr被自动置�?�?br>　　昄��Q�C++没有�q�种机制�Q�但是，可以借助于boost::weak_ptr做到�q�一炏V�?br>

inline void null_deleter(void const *)
{
}

class X
{
private:

    shared_ptr<X> this_;
    int i_;

public:

    explicit X(int i): this_(this, &null_deleter), i_(i)
    {
    }

    X(X const & rhs): this_(this, &null_deleter), i_(rhs.i_)
    {
    }

    X & operator=(X const & rhs)
    {
        i_ = rhs.i_;
    }

    weak_ptr<X> weak_this() const { return this_; }
};

定义变量�Q?br>weak_ptr ptr = x.weak_this(); // x��Z��个X 对象

则当 x 被销毁时�Q�ptr 被自动置为无效。��用方法如下：

if ( shard_ptr safePtr = ptr.lock() ) safePtr->do_something();

�q�种办法用于单线�E�中�Q�因�?x  对象可能是基于栈分配的。如果需要在多线�E�中讉K��X对象�Q�那么最好的办法�q�是使用shared_ptr 来管理对象的生命期。这��L��话，对于safePtr, 可以保证�?safePtr 的生命期内，它所指向的对象不会被其它�U�程删除�?br>

eXile 2007-10-11 11:49 发表评论

D语言与C++

eXile — Thu, 13 Sep 2007 18:26:00 GMT

　　无意中听说了�q�有一�U�Ｄ语言�Q�发现这�Q�还真不赖，��直一个改良的C++高��语言版，兼具�Q�＋�Q�和Java的优点，比那遥遥无期的��E�Q�＋0X 要爽得多�?br>　　�׃��一个晚上，�_�浅得了解了一下，感觉最强烈的有以下几点�Q?br>
　　�Q�１�Q�超快的�~�译速度�Q�编译几百个文�g�Q�只要３�Q�４�U�，估计�Q�＋�Q�要半个��时吧。这是因为它的Module机制实在是比�Q�＋�Q�的include机制强太多了�?br>
　　�Q�２�Q�与�Q�兼容策略：只与�Q�接口兼容，�q�样既能利用现有的��E资源�Q�又不引入��E的低�U�特征。这一点要比��E�Q�＋的完全兼容策略好多了。这��P��Linus大牛也不用叫喊：“你们�q�些搞��E�Q�＋的家伙不要往我这�Q�阵营里�?#8221;。弄得好多�h马上��_�E�Q�＋高不成低不就什么的�?br>
　　�Q�３�Q�完��的宏替代者：Mixin　　

　　�Q�４�Q�对象既可以由gc��理�Q�也可以手动��理�Q�倒是和C++0x有些像�?所以还可以�l�合析构函数实现�QԌ��Q�ﾃ�Q�这一点Ｊ�Q�）�Q�是没有办法的（Java只能用丑陋的try catch块来解决�q�个问题�Q��?br>
　　�Q�５�Q�很多新的特征：unittest,　不变式，contract programming, 　��单的模板用法。。�?br>
说了�q�么多好处，再说一下Ｄ现在的最大问题：
　　对于现在�Q�语�a�的发展，既没有一家成熟的商业公司支持�Q�也没有一个有效的开源社区维护，它的设计完全掌握在设计者一个�h手中�Q�它的核心代码也没有完全开源，�q��它的前景呈现��Z��些不�E�_��的因素。如果要用它�q�行商业开发的话，�q�是有点为时�q�早�?br>　　惌��v了Borland和CodeGear�Q�与其弄什么Turbo C++�Q�还不如��L��持这个Ｄ。。�?br>　　又开始Ｙ�Q�了�Q�睡了。。�?br>�?/p>

eXile 2007-09-14 02:26 发表评论

致命断言	非致命断�a�	验证条�g
ASSERT_TRUE(condition);	EXPECT_TRUE(condition);	condition为真
ASSERT_FALSE(condition);	EXPECT_FALSE(condition);	condition 为假

精品熟女少妇av免费久久,亚洲va国产va天堂va久久,久久综合香蕉国产蜜臀AV

说说C++�����指针(1): 关于shared_ptr

最���单的foreach实现(VC & GCC)

[T] 利用QT�q�行web与本地�؜合应用开�?

一个小疑问�Q�C++头文件中的静态全局变量

利用scons�~�译Qt应用

Google C++ Testing Framework Primer(zt)

boost::asio�C�Z��HTTP Server�c�d��

两个�����y的开源解析库

utf8�~�码转换

GCC4.3...

设计Qt风格的C++API (zt)

设计Qt风格的C++API

便利陷阱

布尔参数陷阱

命名的艺�?/h2> 命名�Q�大概是设计API时唯一最重要的问题了。该怎么�U�呼�q�个�c�？成员函数该叫什么？

�l�类命名

�l�函数和参数命名

例子�Q�QProgressBar

vector的有序化操作

QT中异形窗口的�l�制

悬挂指针与boost::weak_ptr

D语言与C++

说说C++��指针(1): 关于shared_ptr

最��单的foreach实现(VC & GCC)

两个��y的开源解析库

命名的艺�?/h2>
命名�Q�大概是设计API时唯一最重要的问题了。该怎么�U�呼�q�个�c�？成员函数该叫什么？