将C++从VS2003迁移到VS2005需要进行哪些代码更改？
我们正在考虑我们的跨平台的C++从MS Visual Studio 2003中的应用程序的win32构建移动到MS Visual Studio 2005中（是的，极具前瞻性的我们;）将C++从VS2003迁移到VS2005需要进行哪些代码更改？
我们应该期待很多代码更改让它编译和工作？
我刚刚从VS2003通过VS2005迁移到VS2008的相对较大的代码库，我发现的大多数问题都是const/non-const问题，如分配函数的返回值，该函数返回一个const char *到char * 。当涉及到const的正确性时，VS2005和VS2008都更挑剔，如果你现有的代码库有点草率，对不起，老生常谈的正确性，你会看到很多。
一个非常值得欢迎的变化是，VS2005中的模板支持明显好于VS2003中的模板支持（它本身就是对早期版本的一个重大改进），这使我能够抛出针对模板相关问题的几种解决方法，自从VC++ 4.x令人兴奋的日子以来一直在拖延。
您可能遇到的一个问题是关于“不推荐使用”或“不安全”函数的吨警告，特别是如果您使用C字符串函数。很多这些“被微软弃用”（只是他们忽略了“由微软”部分），仍然是完全可用的，但是已知的潜在的缓冲区溢出来源。在我转换的项目中，我设置了预处理程序define _CRT_SECURE_NO_WARNINGS，并禁用了警告C4996来关闭这些令人讨厌的消息。
我们碰到的另一个问题是，MS已经改变了VS2005或VS2008中默认的time_t大小（我道歉，但我不记得 - 它绝对在VS2008中，但它可能已经在VS2005中），所以如果您必须与在接口中使用time_t的遗留库链接，则必须使用_USE_32BIT_TIME_T来恢复较早的编译器的行为。
如果您的解决方案包含多个项目，您可能会发现并行构建功能（默认打开）将突出显示缺少的构建依赖关系。因此项目突然以错误的顺序构建，但如果您从并行构建恢复为线性构建，则魔法构建正确。
总的来说，我更喜欢VS2005/8到VS2003，如果这是一个选项，我会建议升级到VS2008，因为编译器比VS2005“更好” - MS似乎在改进本机方面做了大量工作C++编译器。其中一部分在2005年已经引人注目，因此即使坚持到2005年，您也至少可以获得一些好处。
不，我不希望超过几个。
编辑：您应该/可以先尝试使用vs2005的演示版的代码。
你会发现很多字符串命令会给你警告，如在2005年，他们加强了安全性，试图阻止缓冲区溢出。
你的2003代码仍然可以编译。
如果你的代码已经很干净并且没有警告地编译，这不是一大步。
检查this article并考虑这些更改对现有代码的影响有多大。清理环路一致性可能有点工作。
您可以免费获得Express Studio版本的Visual Studio 2005 here。
我最近将一个10年的VC6程序转换为VS2008。它不需要对源代码进行任何更改，并且升级向导只处理项目文件所需的唯一更改。
如果您的源代码符合C++标准，则不需要更改任何内容即可移动到2005年。您可能会收到一些折旧的警告，但没有任何内容会导致编译错误。
人们从VS旧版本转向新版本的主要问题是新版本更符合标准。
事情是这样：
for(i = 0; i < length; ++i)
{
}
时i之前在VS以前版本的那点做工精细不确定，但在2005年，它标志着正确i作为未定义的变量。
该警告很容易通过定义_CRT_SECURE_NO_WARNINGS – Enno 2008-11-13 10:23:35
来禁用，但并不意味着你应该 – Lodle 2008-11-14 01:16:52
那么，这是一个哲学问题。你*不应该*做的是使用MS-only函数，这会混淆代码的可移植性。 – Enno 2008-11-14 09:02:44