[原创&交流]慎用VC 6.0
链接：慎用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开发。
有些人对自己的语言或工具拥有一种宗教般的情结。我自认在这方面还不是很强烈。有时我在想我们的目的是为人类提供更好的计算能力，而不是把精通某种技术。固守一种技术或者工具，会不会妨碍我们的进步呢？
[解决办法]
我连VS2003都觉得难用，要是用了stl容器，特别是map，调试的时候想看看元素的值，那简直是噩梦。
[解决办法]
VC2005比VC6.0更严格。
比如：
for(int i=0;i<10;i++)
{}
for(i=0;i<20;i++)
{}
上述代码，VC6.0可以，VC2005不可以。
[解决办法]
VS2005对于C++标准支持的更好。但是也更慢些，特别吃内存。
我现在做的一个项目一个Solution有100多个project，ReBuild一次需要半小时还多。
开始怀念6.0
[解决办法]
并不是什么大问题 可能是200X表现太滥 ms故意的吧 去掉调试信息就可以（当然这也意味着你不能在里面F5调试 但是写个logfile也行）
还有一种方式可能略有隐患 就是把这个出问题的lib 用一个旧的替代 sdk里的lib文件也是新旧夹杂的 可以做一个目录放一些不兼容的lib文件的较旧版本 比如uuid.lib之类 在include中设置这个目录优先 基本上都可以跑（目前没有碰到不能的）
真不兼容的地方 是旧版cl包括midl有一些关键字不认识 不过这也好办 既然都不加调试信息了 干脆用vc6+新版的cl 设置一下可执行文件的优先顺序就行
还有就是版本不一定要用最新的 还有就是web service这玩意儿本来就不咋的 何不告诉客户这咚咚慢 只是把原来能做的事情用更慢的方式重新作一遍就像vs200x
还有COM+组件据说通过配置就能变成web service 你做成COM+组件好了
http://msdn.microsoft.com/en-us/library/ms678858(VS.85).aspx
而且都做成COM组件 vc6/vc200x源代码一级不兼容的苦恼基本上就没有了 多好
6就是好 光编辑环境快这一点也是200x、2010一万年都做不到的 而且20xx根本是南辕北辙 越来越慢 慢的跟猪一样 所以 继续用6吧 最多+新版的编译器 就已经尽善尽美了
[解决办法]
