C++博客-蔚蓝海岸-最新评论http://www.cppblog.com/luckycat/CommentsRSS.aspx摇曳着曙光, 那支温柔漂亮的笔杆, 用孩子的笔体写下:相信未来!zh-cnWed, 26 May 2010 12:46:43 GMTWed, 26 May 2010 12:46:43 GMTcnblogsre: Google Test测试框架http://www.cppblog.com/luckycat/archive/2010/05/26/116417.html#116422luckycatluckycatWed, 26 May 2010 15:00:00 GMThttp://www.cppblog.com/luckycat/archive/2010/05/26/116417.html#116422GoogleTest同样可以用于测试Win32 GUI Application。
你的想法可能是MFC写出来的应用是没有对应的控制台，所以GoogleTest无法将输出结果显示出来(实际上Win GUI应用程序也可以同时具备Console Output，只不过这需要手工编码实现，默认情况下是没有的)，当然GoogleTest已经考虑到这个问题了，GoogleTest支持将测试结果以XML文件格式输出.参考下面的链接:http://code.google.com/p/googletest/wiki/GoogleTestAdvancedGuide#Controlling_Test_Output

luckycat 2010-05-26 23:00 发表评论
]]>re: Google Test测试框架http://www.cppblog.com/luckycat/archive/2010/05/26/116417.html#116420ouyangouyangWed, 26 May 2010 14:25:00 GMThttp://www.cppblog.com/luckycat/archive/2010/05/26/116417.html#116420

ouyang 2010-05-26 22:25 发表评论
]]>re: C/C++ Debug工具http://www.cppblog.com/luckycat/archive/2010/04/06/108515.html#111726TuotooTuotooTue, 06 Apr 2010 02:25:00 GMThttp://www.cppblog.com/luckycat/archive/2010/04/06/108515.html#111726应该是
#ifndef DEBUG
吧？

Tuotoo 2010-04-06 10:25 发表评论
]]>re: C/C++ Debug工具http://www.cppblog.com/luckycat/archive/2010/03/16/108515.html#109798zmmzmmTue, 16 Mar 2010 00:57:00 GMThttp://www.cppblog.com/luckycat/archive/2010/03/16/108515.html#109798

zmm 2010-03-16 08:57 发表评论
]]>re: 设计的两难:选择异常还是两段构造http://www.cppblog.com/luckycat/archive/2010/03/08/108899.html#109159陈梓瀚(vczh)陈梓瀚(vczh)Sun, 07 Mar 2010 17:28:00 GMThttp://www.cppblog.com/luckycat/archive/2010/03/08/108899.html#109159两段构造的话，你的类的其他成员函数也应该在构造不成功的时候抛出异常，并没有任何区别，我的例外还减少了别人可能忘记第二段构造的概率。

当然这是对一个库的要求，应用程序不一定要如此严格。

陈梓瀚(vczh) 2010-03-08 01:28 发表评论
]]>re: 设计的两难:选择异常还是两段构造http://www.cppblog.com/luckycat/archive/2010/03/06/108899.html#109069luckycatluckycatSat, 06 Mar 2010 13:27:00 GMThttp://www.cppblog.com/luckycat/archive/2010/03/06/108899.html#109069你列举的判断标准都值得借鉴，不过你后续补充的对"例外情况"的处理方式不敢苟同:
因为构造可能没有成功，那么我们需要调用IsAvailable之类的函数，甚至于后续需要因为判断之前构造函数的状态来
对调用的每个成员函数进行"try catch"或者还要从"每个成员函数的返回值中来判断之前的构造操作是否成功".
这种设计是可行的，但对类的使用者来说太复杂.
这种情况下我觉得使用"两段构造"可能更好一些，我们只需要判断"两段构造"是否成功即可，如果构造成功，在后续的成员函数调用过程中，
就再也不用为了确认构造函数的状态来对每个被调用的成员函数进行"try catch"或检查返回值的操作，这样的设计应该更简洁一些.

luckycat 2010-03-06 21:27 发表评论
]]>re: 设计的两难:选择异常还是两段构造http://www.cppblog.com/luckycat/archive/2010/03/06/108899.html#109067陈梓瀚(vczh)陈梓瀚(vczh)Sat, 06 Mar 2010 13:06:00 GMThttp://www.cppblog.com/luckycat/archive/2010/03/06/108899.html#109067
1：如果一个输入错误，调用者必须知道并处理，那么就采用“不处理就崩溃”方法，迫使调用者处理。在C++里面的唯一方法就是使用异常了。举个例子，对一个容器的下标访问越界，这个时候operator[]不可能返回一个可用的返回值，而且也不能用错误信息去污染返回值，譬如返回pair<bool, T>，因此直接抛出异常。

2：如果一个构造函数发生错误之后，这个对象是绝对不能被碰的，那么采用异常。因为在try-catch结构里面，构造函数完蛋了，那么那个正在被构造的对象你是没有办法获取的。

3：异常可以用来在大量函数互相递归的时候（譬如说语法分析器）迅速跳到最外层，此处作为控制代码流程而使用。

这里我也接受一个例外，譬如说2，如果构造函数发生错误但是我并不想立刻抛出异常（因为有些状态在构造函数里面想知道也比较麻烦），那么除了需要一个类似bool IsAvailable()const函数来告诉你以外，所有该类成员的非法操作（譬如说在错误的构造状态下调用一个成员函数）都必须抛出异常，或者【绝对不产生任何副作用】的同时给一个返回值说明调用失败。

陈梓瀚(vczh) 2010-03-06 21:06 发表评论
]]>re: 设计的两难:选择异常还是两段构造http://www.cppblog.com/luckycat/archive/2010/03/06/108899.html#109011chentanchentanSat, 06 Mar 2010 00:55:00 GMThttp://www.cppblog.com/luckycat/archive/2010/03/06/108899.html#109011我的习惯是 模块边界会检查参数合法性，并报告给调用者
模块内部的代码尽量多的用assert

chentan 2010-03-06 08:55 发表评论
]]>re: 设计的两难:选择异常还是两段构造http://www.cppblog.com/luckycat/archive/2010/03/05/108899.html#109002luckycatluckycatFri, 05 Mar 2010 14:40:00 GMThttp://www.cppblog.com/luckycat/archive/2010/03/05/108899.html#109002谢谢赐教!

"像std::invalid_arguement基本没人会去用"这句话说得有点绝对了，用的人应该还是有一些的，可能我们没有接触到.
另外，我们总是被"天朝"代表，想不到这次被 qiaojie 代表了:)

你说"保证参数的正确性是调用者的责任，而不是被调用的函数的责任"，
这一点我也同意，不过我觉得作为函数的设计者，我们不应当对用户所传递的参数有太多理想化的假设，所以我们应当在函数中进行参数合法性的检查，
一方面，可以在函数的入口处尽早发现非法参数的问题，这样就不至于后续会使用错误的参数在函数中进行一些无意义的操作.
另一方面，在函数入口处检查参数的合法性，可以增强函数的健壮性，进一步增强系统的健壮性.
举个例子，如果传递给函数的实参不应该是NULL指针，用户却以NULL作为实参调用函数，假设我们没有进行对应参数合法性检查，
那么后续基于这个NULL实参的操作可能会导致系统"coredump".

对于参数的合法性检查，在debug版本和release版本下应该都需要进行，类似于"assert(0 < age && age < 200);"这种检测参数的合法性的代码只在debug版本下可以起作用，
在release版本下就不起用了，也就不能在release版本下作为参数合法性检查的工具.
在debug版本下，如果assert断言失败，那么我们可以看到对应的abort信息，然后程序异常退出.
实际上这样做可能有的时候并不合适，因为在一些情况下，仅仅是参数非法，我们可以进行相应的处理而不需要系统因此而退出运行.

"强调不要用异常或者错误返回值，是因为盲目的大量使用这类错误处理机制会导致整个项目变得混乱"
这句话如果仅仅是理论上来探讨"如何让系统设计的更优雅"，那么这无疑可以作为一个"系统设计准则"，
但是在实际的开发过程中，有的时候一个函数内部出现"非正常情况"的可能性实在是太多了，我们必须要进行相应的处理.
如果我们既不使用"异常"也不使用"返回错误码"的形式来告知调用者，
那么在反馈给调用者"函数内部出现非正常情况"这一点上我们将"无能为力"，但我们又必须在这一点有所作为.

在大多数情况下，"异常"和"错误码"可能是我们仅有的两个选择方案，如何选择其一作为最终的处理方案，
甚至如何在不使用"异常"和"错误码"的前提下也达到相同的效果，这是一件很"纠结"的事情.


追求系统在架构和代码设计上的完美是开发者的一个方向，但是有时我们需要考虑"追求完美的代价"，
在时间，人力以及成本的多重影响下，很多时候我们必须放弃对最优方案的探索，而选择一种"不那么完美但是可行，可以很好解决问题"的方案.
也许这个时候作为函数调用状态反馈的"异常"和"错误码"机制会在我们的思考和运用范围之内.




luckycat 2010-03-05 22:40 发表评论
]]>re: 设计的两难:选择异常还是两段构造http://www.cppblog.com/luckycat/archive/2010/03/05/108899.html#109000qiaojieqiaojieFri, 05 Mar 2010 13:56:00 GMThttp://www.cppblog.com/luckycat/archive/2010/03/05/108899.html#109000保证参数的正确性是调用者的责任，而不是被调用的函数的责任，如果你对此有疑问的话可以去阅读一下契约式编程。当然，我并没有说不需要去检查参数的合法性，而是强调应该用assert(0 < age && age < 200);这样的断言来检查参数合法性，这个为什么强调不要用异常或者错误返回值，是因为盲目的大量使用这类错误处理机制会导致整个项目变得混乱，如果任意一个带参数的函数都会因为参数非法而抛异常，那么我在外面接到异常的时候会非常困惑，到底该如何正确处理那么多可能出现的异常？如果是用错误返回值的话就更麻烦，每个函数调用都要进行检查，代码及其繁琐。错误处理机制是整个软件设计的重要环节，他不像接口设计那么显而易见，所以在设计上更应该小心规划合理使用，在
哪里会出异常，哪里该接异常应该做到心中有数正确处理，否则就会陷入混乱。
当然，凡事无绝对，我说的这种使用方式并不适用于组件级或者系统级程序，系统级程序必须要采用防御性编程策略来检测参数的合法性并向调用者报告错误（因为无法预期调用者如何调用函数），这常需要付出代价，常导致系统级提供的API接口跟应用程序之间阻抗适配，需要在应用程序内进行适当的封装。而你的例子显然不属于这类程序。

另外你拿std::invalid_arguement出来我觉得毫无意义，C++标准里不成熟不完善甚至很烂的东西多了去，说上三天三夜也说不完。C++的异常机制尤其不完善，备受争议。像std::invalid_arguement基本没人会去用。

qiaojie 2010-03-05 21:56 发表评论
]]>