当前位置：文江博客话题详情

迁移 C++ 需要更改哪些代码？从VS2003到VS2005？

发布于 2024-07-08 15:45:49 字数 138 浏览 8 评论 0原文

我们正在考虑将我们的跨平台 C++ 应用程序的 win32 版本从 MS Visual Studio 2003 迁移到 MS Visual Studio 2005。（是的，我们非常有前瞻性；）

我们是否应该期望进行许多代码更改才能使其编译和工作？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

许仙没带伞 2024-07-15 15:45:50

您会发现很多字符串命令都会向您发出警告，就像在 vis 2005 中一样，它们加强了安全性以尝试阻止缓冲区溢出。

不过你的 2003 代码仍然可以编译。

回复收藏 0 原文

画中仙 2024-07-15 15:45:50

我最近将一个已有 10 年历史的 VC6 程序转换为 VS2008。它不需要对源代码进行任何更改，并且项目文件所需的唯一更改由升级向导处理。

回复收藏 0 原文

鼻尖触碰 2024-07-15 15:45:50

不，我预计不会有更多。

编辑：您应该/可以首先使用 vs2005 的演示版本尝试代码。

回复收藏 0 原文

辞别 2024-07-15 15:45:50

另外，请考虑禁用检查迭代器，否则移植到新版本后性能可能会受到影响版本。

回复收藏 0 原文

灯角 2024-07-15 15:45:50

如果您的源代码符合 C++ 标准，则无需更改任何内容即可移动到 2005。您可能会收到一些折旧警告，但不会出现编译错误。

人们从旧版本的 VS 升级到新版本的主要问题是新版本更符合标准。

像这样的事情：

for(i = 0; i < length; ++i)
{
}

当 i 在此之前未定义时，在以前版本的 VS 中工作正常，但在 2005 年，它正确地将 i 标记为未定义变量。

If your source code conforms to the C++ standard, you shouldn't need to change anything to move to 2005. You may get some depreciated warnings, but nothing that should give compile errors.

The main issue people have with going from older versions of VS to newer ones is that the newer versions are more standard conforming.

Things like:

for(i = 0; i < length; ++i)
{
}

when i is undefined prior to that point work fine in previous versions of VS, but in 2005 it correctly marks i as an undefined variable.

回复收藏 0 原文

久伴你 2024-07-15 15:45:49

我刚刚通过 VS2005 将相对较大的代码库从 VS2003 迁移到 VS2008，我发现的大多数问题都是 const/非常量问题，例如将返回 const char * 的函数的返回值分配给 char *。 VS2005 和 VS2008 在 const 正确性方面都更加挑剔，如果您现有的代码库有点草率，抱歉，在 const 正确性方面老派，您会看到很多这样的情况。

一个非常受欢迎的变化是 VS2005 中的模板支持明显比 VS2003 中的更好（本身对早期版本来说是一个很大的改进），这使我能够针对模板相关问题提出几种解决方法，这些问题是团队自 2005 年以来一直在拖延的问题。 VC++ 4.x 的令人兴奋的日子。

您可能会遇到的一个问题是大量有关“已弃用”或“不安全”函数的警告，尤其是在您使用 C 字符串函数时。其中许多“已被微软弃用”（只是它们省略了“由微软”部分）并且仍然完全可用，但它们是已知的缓冲区溢出的潜在来源。在我转换的项目中，我设置了预处理器定义 _CRT_SECURE_NO_WARNINGS 并禁用了警告 C4996 以关闭这些有些烦人的消息。

我们遇到的另一个问题是 MS 在 VS2005 或 VS2008 中更改了 time_t 的默认大小（我很抱歉，但我不记得了 - 它肯定是在 VS2008 中，但可能已经在 VS2005 中）所以如果你必须链接对于在接口中使用 time_t 的旧库，您必须使用 _USE_32BIT_TIME_T 恢复到旧编译器的行为。

如果您的解决方案包含多个项目，您可能会发现并行构建功能（默认情况下打开）将突出显示缺少的构建依赖项。因此，项目会突然以错误的顺序构建，但如果您从并行构建恢复到线性构建，则会神奇地正确构建。

总的来说，与 VS2003 相比，我确实更喜欢 VS2005/8，如果可以的话，我建议升级到 VS2008，因为编译器比 VS2005“更好”——MS 似乎在改进本机 C++ 编译器方面做出了巨大的努力。其中一部分在 2005 年就已经很明显，因此即使您坚持 2005 年，您也至少会获得一些好处。

I've just migrated a comparatively large codebase from VS2003 to VS2008 via VS2005 and the majority of issues I found were const/non-const issues like assigning the return value of a function that returns a const char * to char *. Both VS2005 and VS2008 are a lot more picky when it comes to const correctness and if your existing codebase is a bit sloppy, sorry, old school when it comes to const correctness, you'll see plenty of this.

A very welcome change was that the template support in VS2005 is noticeably better than it is in VS2003 (itself a big improvement on earlier versions), which enabled me to throw out several workarounds for template related issues that the team had been dragging around since the heady days of VC++ 4.x.

One issue that you are likely to encounter are tons of warnings about "deprecated" or "insecure" functions, especially if you are using the C string functions. A lot of these are "deprecated by Microsoft" (only that they left out the "by Microsoft" part) and are still perfectly usable, but are known potential sources for buffer overflows. In the projects I converted, I set the preprocessor define _CRT_SECURE_NO_WARNINGS and disabled the warning C4996 to turn off these somewhat annoying messages.

Another issue that we came across is that MS has changed the default size of time_t either in VS2005 or in VS2008 (I apologise but I can't remember - it's definitely in VS2008 but it may already be in VS2005) so if you have to link with legacy libraries that use time_t in the interface, you'll have to use _USE_32BIT_TIME_T to revert to the older compiler's behaviour.

If your solution contains several projects, you may find that the parallel build feature (which is turned on by default) will highlight missing build dependencies. so projects are suddenly built in the wrong order but magically build correctly if you revert from parallel build back to linear build.

Overall I do prefer VS2005/8 to VS2003, and I would recommend to upgrade to VS2008 if that is an option, as the compiler is "better" than VS2005 - MS seems to have made a massive effort in improving the native C++ compiler. Part of that was already noticeable in 2005 so you'll get at least some of the benefit even if you stick to 2005.

回复收藏 0 原文