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 回答