C ++代码库从MFC重写为* nix

如何解决C ++代码库从MFC重写为* nix

|| 我在暑假期间在一家公司实习，我必须研究以不同方式查看当前代码库（C ++，MFC，大约10万行），并使用状态机为当前程序建模。 我已经阅读了几篇论文，并且CPP2XMi看起来可能是尝试构建序列图的起点。 最终目标是评估脱离Microsoft作为O / S的可行性，并研究* nix上的开发（可能使用另一种语言）。 我也已经开始研究MFC的依赖关系，以查看是否可以仅移植当前的C ++代码。 我已经在WINE和性能方面运行过该程序，这似乎可以接受，但是我仍然需要研究其他解决方案，因为它只能在X86上运行，而我们有其他运行在MIPS和ARM上的解决方案。 我还有其他想法或警告吗？     

解决方法

        我要看的第一件事是在哪里使用mfc和其他非便携式设备。例如，如果在接口层中只有mfc，则可以隔离工作。 如果没有这种分离，我将研究创建一些独立且可移植的代码部分的可行性。一旦有了可移植性基础，就可以开始抽象非可移植代码提供的所有服务。通过MFC到Nix进行切片的任何方式都是很大的变化，并且需要大量的工作。另一种可能性是查看是否可以在Windows模拟器下运行它。     ,        通过阅读wxWidgets本书，它看起来与MFC非常相似。您可能会看一下。     ,        首先，我将研究GUI是否与应用程序的其余部分分开。对于MFC，这包括将实用程序类（如“ 0”）的使用限制为仅GUI代码。 如果以这种方式对代码进行了很好的分解，则最简单的操作可能是不留下MFC GUI代码，而仅使用每个新平台选择的本机GUI库为其他平台构建新的GUI。这将为应用程序提供适当的本机外观和行为，而这实际上很难以任何其他方式实现。 如果将应用程序逻辑与GUI代码混合在一起，则是时候问您是否可以投入资源来创建适当的分离，目的是在实现分离后执行上述操作。从业务的角度来看，这是有风险的，因为看起来您已经付出了很多努力，而只是回到了起点。直到您在重构的应用程序顶部的新GUI上开始工作时，您的赞助商才能看到任何实际进展。 您还可以查看可移植的GUI库，例如wxWidgets和Qt。 我已经为MFC和wxWidgets编程，它们在概念上非常相似。我从来不需要将代码从一个移植到另一个，但是我曾经从Borland的OWL移植到MFC，这是类似的经历。这种事情并不是特别困难；这只是一个磨。只有在出于多种原因删除旧的GUI库时，才建议这样做。例如，也许您还在考虑完全删除Visual C ++，或者从Professional切换到Express，从而失去对MFC的访问权限。如果您打算坚持使用VC ++ Professional（或更高版本），则很难证明丢弃MFC GUI是合理的。     ,        我曾经将MFC的大型COM库移植到可移植代码。我使用STL和boost替换了所有MFC位。例如，CString => std :: string和VARIANT => boost :: any。 它花了很长时间，但是主要是直接替换和调整。幸运的是，它没有任何GUI代码-它是一个数据处理库。