问题描述
我正在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 Studio2005.这不是一个很大的变化，例如，但只能解决所有不兼容问题错误.
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)
- Breaking Changes VC 2005 - 2008 (VC 2005 -> VC 2008)
- Breaking Changes in the Visual C++ 2005 Compiler (VC 2003 -> VC 2005)
- Breaking Changes in 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应用程序之间的鸿沟.这可能只是封送代理，它只是在主应用程序和第三方组件之间移动数据而已.
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.
这篇关于将MFC中的大项目从Visual C ++ 6.0迁移到Visual Studio 2005的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！