快捷搜索:

慎用VC 6.0

编程生涯虽然以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开拓。

有些人对自己的说话或对象拥有一种宗教般的情结。我自认在这方面还不是很强烈。无意偶尔我在想我们的目的是为人类供给更好的谋略能力,而不是把精晓某种技巧。恪守一种技巧或者对象,会不会阴碍我们的进步呢?

您可能还会对下面的文章感兴趣: