2

您在这样做时预见到的所有问题是什么。

4

2 回答 2

8
  1. Microsoft 不再以任何方式支持 VC 6。如果出现问题并且无论出于何种原因我们无法编译,我们将完全靠我们自己无法从 Microsoft 获得任何帮助。似乎不太可能以这种方式出错,但如果有问题的代码是主要的收入来源,那么你就可以平衡事情了。
  2. 在 VC6 中编译 64 位代码是不可能的。32 位程序在 64 位 Windows 上运行——至少现在是这样。但是,如果您需要利用创建本机 64 位产品的潜在速度和内存增益(例如,能够在单个进程中使用超过 3 GB 的 RAM),那么 VC6 就出局了。
  3. VC9 具有更好的标准合规性。VC6 的标准合规性非常差。这实际上既是移植的原因,也可能是不移植的原因。使用 VC6 的程序员习惯于以“错误的方式”做事,并且需要重构大部分代码才能在 VC9 中工作。

上面 #3 的一个简单示例是 for 循环:

for( int n = 0; n < someMax; ++n )
{
  // do stuff
}

printf("Did %d stuffs", n);

此代码在 VC6 中有效,但在 VC9 中无效。它实际上是一个格式错误的程序——事实上 VC6 允许它是 VC6 中的一个缺陷。

从 VC6 移植到 VC9 的决定并不是一个灌篮高手。您必须考虑项目的难度,并与您获得的任何收益和避免的任何问题进行平衡。

在决定是否以及如何开展此项目时,您应该查看 Microsoft 的重大更改列表。第一个列表,从 VC6 到 VC7 的重大更改,是一个巨大的列表。相比之下,其他的要小得多。这表明如果你从 VC6 移植到任何东西,它应该至少是 2005。

于 2008-11-24T16:24:43.200 回答
3

你说的代码库有多大?

移植一个小程序(主要是非模板化的 C++ 代码)应该是相当简单的。

然而,我曾经不得不将 100.000 行使用模板的代码从 VC6 转换为 VC2005,这是噩梦般的一周(工作 5 天),主要问题是我必须手动修复大约 30% 的问题(70 % 相当微不足道,可以通过搜索和替换来修复它们)。但更多的问题是旧代码没有测试用例和测试框架,所以即使我让应用程序编译并且没有段错误,看起来还不错(?),我不能保证它实际上工作的一切正如它应该是的那样。

所以实际上我的建议是考虑代码的大小和测试的可用性,还要考虑代码是否真的需要移植(在我的情况下是的,但并非总是如此,特别是如果软件很快就会淡出)

于 2008-11-18T07:46:15.560 回答