从多种解决方案中选择最优方案

作者:朱金灿
来源:
http://blog.csdn.net/clever101

      如果你问我软件开发有什么经验的话,那么我的一条经验就是:尽可能设想多种解决方案,在多种解决方案中选择一种代价较少的最优解决方案。比如今天解决了一个问题便是这条经验的一个证明。今天我将一个VC 6的工程转为VS 2008工程,在编译时遇到了问题,原因是里面用到了一个开源字符串类CStringEx,它派生自CString。CString在VC 6的实现中有一个数据成员m_pchData,在CStringEx类中自然也用到了这个数据成员。但在VS 2008中的CString的实现完全没有了m_pchData这个数据成员。VS 2008中的CString实际叫CStringT。因此在编译工程时自然而然遭遇到m_pchData未定义的错误。

      因为这个工程必须用到CStringEx类,而CStringEx类的多处地方都用到了m_pchData这个成员。一开始我不知道如何想办法替代m_pchData(我大致能猜到它是表示字符串的首地址),直接的做法是自己仿照VC 6中的CString类实现一个字符串基类,然后将CStringEx类派生自该类。但是一看VC 6的CString类的实现,感觉这个解决办法代价较大,因为要用到VC底层的太多的宏和基类。虽说这个办法也能解决问题,但我想应该不是最优解决办法。我想到既然它是开源代码,在VC 6下实现,那么如果别人把它在VC 6以上的版本上编译,也必然会遇到问题,这样上网搜索说不定能找到别人提到的解决办法。于是我在google上输入:CStringEx进行搜索,果然找到一条有用的资料:

I don't like the idea of using #define to fool the compiler -- it seems to me like a hack that could easily bite you in the a$ later on down the road. i'm using VS8. so to fix CStringEx, i replaced all 22 instances of "m_pchData" with (LPTSTR)GetString(). there were three exceptions in the FindReplaceNoCase() function where i needed to replace something like sLowerThis.m_pchData with (LPTSTR)sLowerThis.GetString(). (same for sLowerSub) after i did that, my CStringEx class was happy once again ;-)

     按上面说的一试,编译通过。因此在解决问题时首先应设想尽可能多的解决方法,分析各种方法的潜在风险,选择最优的解决办法。

原文地址:https://www.cnblogs.com/lanzhi/p/6471098.html