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

作者：朱金灿

来源：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 ;-) 

 

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