慎用VC 6.0

作者：朱金灿

来源：http://www.cnblogs.com/clever101

 

      编程生涯虽然以tc 2.0开始，但是VC 6.0也曾经陪伴我颇长一段日子，现在说一些批判它的话，别有一番滋味在心头。还是以我的一段项目经历作为引子吧：

 

前一段时间升级一个系统（系统不是我做的,是其它同事采用VC 6.0开发的），主要是增加一个游戏手柄接口。我上网搜了一下，决定采用DirextX的DirectInput来做，恰好这个系统之前就用了d3dx9.h里的接口。我自然而然地选择DirextX 9.0 SDK。

 

于是我下载了Direct X9.0 SDK April 2007。结果编译工程时出现了一个错误：

Linking...

dxguid.lib(dxguid.obj) : fatal error LNK1103: debugging information corrupt; recompile module

Error executing link.exe.

 

    上网查了一下，基本上确认是Direct X9.0 SDK和VC 6.0的兼容问题。开始我选择了尝试将VC 6.0工程转为VS 2005工程。结果编译后出现几十个错误，解决了大部分之后一时还有几个未搞定。此时我决定换一种解决思路：看看微软有没有提供支持VC 6.0的DirextX 9.0 SDK。结果还真让我找到了：DirectX 9.0 Summer 2004 SDK和DirectX 9.0 Summer 2004 SDK Update Extras。重新下载这两个库后问题得以解决。

 

虽然问题得以解决，但我开始思考使用VC 6.0进行项目开发所面临的风险。一直以来我对部门一些同事还采用VC 6.0开发是有些看法的。现在看VC 6.0存在着诸多的缺陷。虽然从现实的角度去批判VC 6.0不太历史唯物主义，但是我们还是需要从现实的角度去评估潜在的风险。

 

首先是微软现在基本不对VC 6.0进行维护，也不会就其新的开发包开发专门支持VC 6.0 的版本。在这种情况下使用VC 6.0就意味着我们很难使用最新的技术。

 

其次是VC 6.0对C++标准支持不好。这会有两方面的后果：一是无法使用C++标准中更为灵活的用法，比如一些模板用法；另一方面在跨平台移植时会遇到麻烦。现在我还难理解VC 6.0为何会支持诸如static i ; 这样的代码，要知道C++是一种强类型的语言。当然一些大侠推荐VC 6.0 + intel c++ 9来打造完美的标准C++ IDE，说实话，这在道理上说得通，但是事实上不太可行。首先intel c++ 9要花不少银子的。其次我不想为编译一个工程而去安装两个大型软件，特别带着这两大软件去客户那边调试系统。

 

三是VC 6.0的补丁实在太多，足有6个补丁之多，更绝的是从界面上你不知道你是否安装了sp5或者sp6。所以有时搞得我很迷糊，这个软件是在VC 6.0 + sp5下开发的还是VC 6.0 + sp6下开发的呢。当然有些稍微复杂的方法可以判断安装了哪些补丁：如何判断是否安装了 Visual Studio Service Pack。

 

四是VC 6.0现在已无法适应用户的需求和为项目提供一体化的解决方案。我曾碰到这样一个项目：一期工程单纯是一个桌面系统（我们在一期中使用VC 6.0开发）。到了二期工程，客户要求具有WEB Service功能，结果我们还得安装一个VS 2005 以开发WEB Service。VC 6.0主要作为一个桌面开发工具而流行，但到现在已很难适应项目的混合架构类型（既有C/S 系统，也有B/S系统），更别提提供解决方案了。我相信解决方案是一个符合软件开发潮流的概念。对用户来说，解决方案就是我们为用户提供从数据采集，数据加工处理到成果输出一体化服务，对微软来说，解决方案就是为我们提供从软件设计，软件开发到软件测试和软件发布的一体化服务。VC 6能提供解决方案吗？

 

因此对于已用VC 6.0开发的历史项目，就得过且过吧，不到万不得已不移植到更高的VS版本；对于正在用VC 6.0开发的项目，评估一下其中的移植风险，如风险不大，主张移植；对于还没进入开发阶段的项目，坚决不用VC 6.0开发。

 

有些人对自己的语言或工具拥有一种宗教般的情结。我自认在这方面还不是很强烈。有时我在想我们的目的是为人类提供更好的计算能力，而不是把精通某种技术。固守一种技术或者工具，会不会妨碍我们的进步呢？