【问题标题】:Do any automated conversion tools exist for porting C++ code to 64-bit?是否存在用于将 C++ 代码移植到 64 位的自动转换工具?
【发布时间】:2011-09-11 04:13:50
【问题描述】:

我正在研究将大量(>10M 行)C++ 代码移植到 64 位的方法。我已经研究了静态代码分析器和编译器标志,现在我正在研究可以进行常见重复更改的宏或其他工具。

我已经编写了一些正则表达式来看看它们在实践中的效果如何,并且正如预期的那样,它们非常有效。也就是说,首先构建表达式需要一段时间,所以我想看看是否有任何此类表达式的列表或可以自动执行更改的软件工具。

以下几行是要匹配和修复的代码的原型示例。 (澄清一下,这些行并不代表单个代码块,而是从不同地方提取的行。)

int i = 0;
long objcount;
int count = channels.count(ch);
for (int k = 0; k < n; k++) { /*...*/ }

目标不是将代码彻底移植到 64 位,而是对代码执行第一次传递以减少需要手动检查的代码量。遗漏一些必要的更改是可以的,可能可以进行一些错误的更改,但应尽量减少这些更改。

Visual Studio 是将用于转换工作的 IDE,因此与 VS 配合良好的东西是一个加号。成本不是问题。

【问题讨论】:

  • 这些行在什么意义上需要修复?
  • @Oli:示例没有显示,但int count 可能太小,无法容纳channels.count 的size_t 返回。在 for 循环中,int k 可能会在达到long n 的大小之前进行换行。等等。
  • @Henry 为什么在 32 位中 int Ok 而在 64 位中却不行?
  • 在我移植的代码中(诚然,在编写时考虑到了可能的 64 位端口),编译器将所有问题作为警告突出显示。修复并不总是提升到 size_t;在某些情况下,需要添加强制转换(或运行时检查)以明确 32 位是合适的。
  • @Henry:我怀疑你能找到这样的工具,因为当你移植它时,正确代码工作得很好。错误代码的问题在于它不遵守任何规则,因此自动化工具很难处理。

标签: c++ 64-bit 32bit-64bit


【解决方案1】:

Rexexp 的误报率很高;根据定义,“正则表达式”不能解析上下文无关的语言,例如 C++。此外,正则表达式不能考虑 账户类型信息;是

   fooT i=0;

好的,对于某些类型定义的脚?最后,正则表达式不能更改代码;您可能会考虑 Perl 或 SED(使用正则表达式来驱动更改),但由于正则表达式的误报,您会得到错误的更改。在 1000 万 SLOC 上,这可不好玩; 5% 的错误率意味着可能需要手动修复 50,000 行代码。

您可以考虑使用program transformation 工具。这样的引擎在语言结构上运行,而不是文本,更复杂的版本知道范围、类型和符号的含义(例如,什么是 fooT,究竟是什么?)。它们使您能够使用目标语言的表面语法编写特定于语言和上下文的模式,并提出结构上正确的代码更改。这可以实现大规模可靠地应用代码更改。

我们的DMS Software Reengineering Toolkit 及其C++ Front End 已用于以语法和类型准确的方式对大型C++ 系统进行大规模更改。 (参见 Akers, R.、Baxter, I.、Mehlich, M.、Ellis, B.、Luecke, K.,案例研究:通过自动程序转换、信息和软件技术重新设计 C++ 组件模型 49(3): 275-291 2007。)

【讨论】:

  • 我使用自动化的目标是减少需要手动检查的代码量,而不是解决所有问题。是的,正则表达式可能会出现误报,而且它肯定不会捕获所有内容,但该工作的理想表达式本质上是保守的。您的工具包看起来很有趣,但是除了比正则表达式“更智能”之外,它还有什么帮助呢? (换句话说,除了识别表达式并根据某些规则更改它们之外,它还可以执行任何其他重组吗?对于 64 位转换项目它会做多少?)
  • @Henry:关于误报的争论是你能容忍多少。一个真正保守的探测器说一切都需要注意,但这完全是在浪费你的时间。您想要的是您可以获得的最紧凑、最保守的检测器,并且需要使用名称解析进行真正的解析才能做到这一点。我很惊讶我关于 fooT 的例子没有说服力。除了保守地说,没有正则表达式可以帮助你,总是说“可能是错的”。 ...
  • @Henry: ...也就是说,像 DMS 这样的工具的价值在于它不仅可以检测到您可能有问题,而且实际上可以对代码进行更改。您甚至可以通过实验进行此类更改(因为您始终可以在原始资源上再次运行该工具的修订版本)。因此,您可以获得更好的检测、更少的误报和(一些)自动更改。与正则表达式相比,有什么不喜欢的? 10M 行是一大堆代码。
  • 我同意它可以提供比正则表达式更好的检测甚至更好的更改(尽管我必须指出正则表达式可以修改代码)。不过,Regex 是免费的,并且支持内置在 Visual Studio 中(尽管使用了令人讨厌的 regex 语法)。我不怀疑 DMS 是一个强大的工具,我只是不确定成本与收益之间的关系。对于初学者,我需要哪些包同时使用 ANSI 和 VC++6 代码?之前有没有使用过 DMS 辅助 64 位转换?
  • @Henry:欢迎您在 VS 中输入正则表达式来满足您的需求(当您拥有 10M SLOC 时,它的响应速度如何?)我只是不相信您有心这样做10M SLOC 以及您可能发现的所有问题。对于 DMS,您只需要 VC++6 前端; AFAIK,它完全包括ANSI。 DMS 之前没有用于 64 位转换;它已被用于自动化大规模 C++ 源代码的架构重组。
【解决方案2】:

您使用的是什么版本的编译器?您是否尝试使用 /Wp64 标志运行编译器来检测到 64 位的可移植性问题?

来自 MS 网站: “/Wp64 检测同样用 __w64 关键字标记的类型的 64 位可移植性问题。/Wp64 在 Visual C++ 32 位编译器中默认关闭,在 Visual C++ 64 位编译器中默认开启。”p>

http://msdn.microsoft.com/en-us/library/yt4xw8fh%28v=vs.71%29.aspx

【讨论】:

  • 是的,我查看了/Wp64 标志。这很有帮助,但它会产生太多警告,无法单独检查整个代码库中的每一个。
  • 该标志现在已弃用。只需运行带有 64 位目标的编译器,您就可以获得更准确的诊断。 (您甚至可以在 32 位平台上执行此操作。)
  • 该标志是在 VS2005 中引入的,用于“准备”您为 64 位平台编写代码。但是在 VS2008 中它被认为已经过时了,您应该直接使用 x64/IA64 作为目标平台进行构建。
猜你喜欢
  • 1970-01-01
  • 2015-01-25
  • 1970-01-01
  • 2011-01-24
  • 2010-12-01
  • 1970-01-01
  • 1970-01-01
  • 2014-04-27
  • 1970-01-01
相关资源
最近更新 更多