将 MFC 中的大型项目从 Visual C++ 6.0 迁移到 Visual Studio 2005
我在 Visual C++ 6.0 中维护一个大型项目(约 250k loc，不计算从 idl 生成的代码)，它使用 Visibroker(简称 VB)5.2.1(这是 Borland 的 CORBA 实现).最近，与我的项目通信的另一个模块升级到了 VB 8.0，我遇到了一堆不兼容的问题.由于 VB 5.2.1 不再受支持，而 VB 8.0 不适用于 Visual C++ 6.0，我正在考虑将整个项目迁移到 Visual Studio 2005.这不像 用 C# 完全重写大型 C++ 应用程序?，但只解决所有不兼容问题错误.
I am maintaining a big project (~250k loc, not counting code generated from idl) in Visual C++ 6.0, that uses Visibroker (VB for short) 5.2.1 (which is a CORBA implementation from Borland). Recently, the other module that communicates with my project was upgraded to VB 8.0 and I got a bunch of incompatibility issues. Since VB 5.2.1 is no longer supported while VB 8.0 does not work with Visual C++ 6.0, I am considering migrating the whole project to Visual Studio 2005. It is not a big change like total rewrite large C++ application in C#?, but only resolving all the incompatibility errors.
我的问题是我应该使用什么样的策略来完成这项任务?以前有人做过吗?此外，对我来说，问题是项目的规模.做这种迁移需要多少努力?
My question is what kind of strategy should I use to tackle this task? Anyone has done this before? Also, the problem for me is the size of the project. How much effort does it take to do this kind of migration?
仅供参考，该项目在 MFC 中有一个前端 GUI 部分和一个后端 CORBA 部分.两者虽然不是很好分开.
FYI, the project has a frontend GUI portion in MFC and a backend CORBA portion. The two are not very well separated though.
最好的问候.
推荐答案
我在 这篇文章.去年我将一个百万行的单体应用从 VC6 移植到 VC9，结果证明非常困难.VC6 因即使在问世时也不太符合标准而臭名昭著，随着标准在随后几年的发展，VC6 的合规性变得更糟.微软借此机会在 VC7 中很大程度上修复了这个问题，但这样做破坏了很多在 VC6 中编译的代码.
I adressed porting from VC6 to VC9 in this post. I ported a million-line monolithic app from VC6 to VC9 last year, and it proved to be extraordinarily difficult. VC6 was notorious for being not very Standards-compliant even when it came out, and as the Standard evolved in the following years, VC6's compliance just became worse. Microsoft took the opportunity to fix this problem in VC7 to a large degree, but in doing so broke a lot of code that compiled in VC6.
在某些情况下，代码出错是因为代码本身很糟糕，而 VC7 是一个更好的编译器，它不允许 VC6 提供的许多自由.但在许多情况下，好代码"(从 VC6 的角度来看)由于一致性的提高而变成了非法代码.一个很简单的例子:
In some cases the code broke because the code itself was poor, and VC7 was a much better compiler that did not allow many liberties that VC6 did. But in many cases "good code" (from VC6's point of view) became illegal code because of the increased conformance. A very simple example:
for( int i = 0, cont = 1; cont; ++i )
{
// count something up
}
cout << "The number is now " << i << endl;
就 VC6 而言，这段代码非常好，但根据标准，i 超出了 for 块末尾的范围.从 VC6 到 VC7(以及从 VC7 到 VC8 等)，还有很多其他类似的例子.在继续之前，您应该仔细查看这些更改:
This code is perfectly fine as far as VC6 is concerned, but according to the Standard i falls out of scope at the end of the for block. There are many, many other examples of things like this that changed from VC6 to VC7 (and from VC7 to VC8 etc). You should review these changes carefully before you proceed:
- 突破性变化 VC 2005 - 2008 (VC 2005 ->VC 2008)
- Visual C++ 2005 编译器的重大更改 (VC 2003 -> VC 2005)
- Visual C++ .NET 2003 (VC6) 中的重大更改-> VC 2003)
除了更好的合规性之外，我们还有许多令人信服的理由转向 VC9.一是能够编译 64 位应用程序，因此我们最终决定移植整个应用程序.但你可能有其他选择.
We had many compelling reasons to move to VC9 beyond just better compliance. One was the ability to compile 64-bit apps, and so we eventually decided to port the entire app. But you may have alternatives.
如果编译器仅在代码的一部分中为您创建了障碍，您可能会考虑仅移植该部分，并创建一个在 VC9 中编译的层，以弥合 VB 8.0 和 VC6 应用程序之间的差距.这可能只是一个编组代理，它只是在您的主应用程序和第 3 方组件之间移动数据.
If the compiler is creating a roadblock for you in just one portion of the code, you might consider porting just that portion, and creating a layer compiled in VC9 that bridges the gap between VB 8.0 and your VC6 application. This could be little more than a marshalling proxy, that does nothing more than move data between your main application and the 3rd-party component.
相关文章