`
ladymaidu
  • 浏览: 674044 次
文章分类
社区版块
存档分类
最新评论

慎用VC 6.0

 
阅读更多

作者:朱金灿
来源:
http://blog.csdn.net/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开发。

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

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics