VC6向左?VC2005向右?
我这边从Google和MSDN上搜集到一些关于VC6和VC2005的对比,另外加上了一些个人的感觉来看一下我们平时在开发应用程序的时候到底是选用VC6还是VC2005呢?
|
VC6 |
VC2005 |
备注 | |
编译速度 |
快 |
慢 |
-- | |
对C++标准和STL的支持程度 |
不好,特别是对一些模板库的支持不好,例如list; 某些C++语法要求不是很严密,最明显的就是for循环中的初始化变量 |
对C++标准支持更好,更严密 |
VC6发布的时候,当时国际C++组织还没有将C++完全标准化,所以VC6对C++标准的支持不好是理所当然的。据说可以使用Intel C++ 8.1来代替VC6的库即可支持C++标准 http://blog.csdn.net/lonelyforest/articles/663934.aspx | |
调式多线程 |
偶尔莫名其妙会Freeze,只有把进程Kill掉后重新来过 |
未发现问题 |
VC6 SP6可能解决这个问题? | |
内联汇编代码的书写 |
偶尔会提示非法操作 |
未发现问题 |
-- | |
Tab页浏览 |
不支持 |
支持 |
VC6可以通过第三方插件实现像VC2005一样的多Tab式浏览 | |
Custom Build Rules |
不支持 |
支持 |
这项功能可以在Visual Studio中实现混合交叉编译,例如在VC2005中可以直接将*.cu文件编译成CUDA模块,或者将.fx文件编译成Shader执行文件等等。VC6中却不能这么做。 | |
内存管理 |
在Vista及其后续操作系统上可能有问题 |
SP1版本的VC2005不会有问题 |
Visual Studio 98发布之时并没有考虑到今天的Vista这么严格的内存管理,因此可能存在兼容性问题。所以在Vista上安装VC6的时候,会给出提示,虽然我们可以强制安装,但是在运行的过程中可能会产生缓冲溢出问题 | |
64位硬件驱动开发 |
不支持 |
支持 |
-- | |
对SDK的支持 |
可能不支持最新的SDK |
目前支持最新版本的SDK |
像VC2008 SDK,微软官方是声明VC6不支持的。MS声称VC6最新支持到Platform SDK for Windows 2003 | |
是否需要额外的vcredist_x86.exe分发包 |
不需要 |
需要 |
这恐怕是最严重的问题了,VC6 CRT和MFC对应的DLL在XP后的系统上都自带(msvcp.dll需要额外添加) VC2005则要考虑再发布包的问题 | |
编译出来的模块的尺寸 |
-- |
-- |
VC2005相比于VC6并不会在尺寸上有什么优势。(需验证) | |
代码编写和调试效率 |
低 |
高 |
由于VC2005在IDE上较VC6有大的更新,所以其开发效率是VC6所不能比拟的。至于调试效率,也是VC2005较高,例如VC6中只有一个Memory查看窗口,而VC2005则同时提供了4个Memory查看窗口:
| |
VC6的Memory Output Window |
VC2005的Memory Output Window | |||
|
当然实际中,我们还是可以忽略Vista的兼容性警告而安装VC6,但是很明显的,如果出了什么兼容性问题的话,就无法从MS获得任何帮组了。
另外,关于GPU编程时候使用的编译器:
1. CUDA
1.1版本之前的CUDA的编译器nvcc是支持VC6.0的;
在1.1版本的CUDA中正式移除了对VC6.0的支持;
从2.1 Beta开始,将Visual Studio 2003 .NET Project从CUDA移除,(应该也说明不再支持VC2003了),而加入对Visual Studio 2008 Project的支持
现在nVidia官方发布的CUDA最新版本是2.2,nvcc现在只支持vs2005和vs2008了。当然,可以用vs2005或者2008开发出来lib或者dll,让vc6调用;也可以直接编译cu kernel到bin文件,然后用加载kernel的方式调用。
2. ATi Stream
AMD官方宣称:
ATi Stream SDK v1.4-beta支持Visual Studio 2005和Visual Studio 2008
ATi Stream SDK v2.0-beta2只支持Visual Studio 2008
综上,不论是CUDA还是ATi Stream,都是需要至少VC2005以上的编译器的。
个人感觉:
1. 如果VC2005再分发包真的成为应用程序中的一个致命缺点的话,那么只好将所有的模块转回VC6。
2. 从上面的GPU编程所使用的编译器来看,像nVidia和AMD这样的大厂都已经开始放弃10年前的VC6了,我们又有什么理由还使用VC6呢?如果应用程序是要和GPU打交道的,既然连GPU编程都要用到VC2005,那么就是说一定会涉及到VC2005再发布包的问题。
3. 连微软自己都不再支持VC6了,为什么我们还要坚持阵地?
4. 诚然,VC2005中的manifest和再发布包问题的确令人很头痛,但是我们更多地要看到为什么微软要引入这个东东背后的深意。平心而论,我们这边根本没有用到manifest来部署独立应用程序和程序集的经验(Web程序和托管代码中使用的最多),所以可能根本没有办法体会到manifest的好处,只会感觉到VC2005再发布包是一个很烦人的东西。况且VC2005本身并不像VC2008那样内置有更为强大的Manifest编辑工具,所以我们还要使用额外的工具去修改EXE或者DLL资源文件中的Manifest信息。这样就更怀念VC6的好处了。
但是,我们都是“丐帮”的人,既然盖茨老大从WinXP以后都主推这个Manifest技术了,那我们也只应该跟上时代的潮流,而不是逃避了。
5. 从个人感情上来说,更喜欢使用VC2005,因为使用VC2005的确开发效率要高很多。我们与其花时间去将VC2005工程回滚到开发效率低下的VC6,还不如将这些时间用在开发更好更新的功能上。
以上,一家之言,欢迎拍砖。