Question

你预见到的所有问题都是什么。

Answer 1

Microsoft 不再支持VC 6。如果出现问题，无论出于什么原因我们都无法编译，我们将无法获得微软的任何帮助。以这种方式出现问题似乎不太可能出现问题，但如果有问题的代码是主要的收入来源，那么你就可以平衡。
无法在VC6中编译64位代码。 32位程序在64位Windows上运行 - 至少目前如此。但是，如果您需要利用创建本机64位产品的潜在速度和内存增益（例如，在一个进程中能够使用超过3 GB的RAM），那么VC6就不存在了。
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年。

Answer 2

您谈论的代码库有多大？

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

然而，我曾经不得不将100.000行模板使用代码从VC6转换为VC2005，这是一个噩梦般的一周（工作5天），主要问题是我必须手工修复约30％的问题（70％是相当微不足道的，可以用搜索和替换来修复它们）。但更多的问题是旧代码没有测试用例而没有测试框架，所以即使我得到应用程序编译而不是段错误，看起来没问题（？），我也无法保证它实际工作的一切因为它应该是。

所以实际上我的建议是考虑代码的大小和测试的可用性，还要考虑代码是否真的需要移植（在我的情况下是的，但并非总是如此，尤其是如果软件即将淡出）

真的值得从VC6移植 - ＆gt; vc2005,2008？

2 个答案: