c++ - C/C++ 的重构工具如此有限的原因

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




10年前关闭。




没有是什么问题工业级 C/C++ 的重构工具已经创建，我只需要一个“正常工作”的工具？

我所说的“工业水平”是指 JetBrains 产品(IntelliJ、ReSharper)或更高版本提供的质量。任何可用的解决方案(包括 Tomato Software 的 Visual Assist 或 Eclipse CDT)都不够成熟。

以下是初创公司插入此类项目的优势。

缓解 C++ 枯燥的语法(让开发更有趣)；

C++ 正在发展(0x 版本即将到来，因此这些工具实现者需要做很多工作)；

营销利基比其他任何东西都广泛(大量编写的 C++ 代码，大量活跃的 C++ 项目)，甚至考虑到 Web(HTML/JavaScript)项目；

C++ 被用于系统问题，其中工具在编译时发现的每个错误都是一个生存(很多公司或政府应该感兴趣)；

这样的工具可以减少项目编译时间；

唯一的缺点是技术上的挑战……但是看看谷歌、微软、英特尔等公司在做什么，应该没有无法解决的技术问题。

让我们总结一下:

可以实现这样的产品

利润丰厚

不存在

没人想赚钱？勾结;) ?原因是什么？

Answer 1

让我们只考虑一种基本的重构:重命名函数

实现看起来非常简单。查找所有引用，并替换使用的标识符。

使用虚函数会变得更复杂一些。现在有必要找到基本声明(和实现，如果不是抽象的)，并且引用可能指向类层次结构中的任何派生实现。困难得多，但仍然可行，因为要重命名的函数组是明确定义的。

这就是适用于 C# 和 Java 等语言的复杂性。现在是踢球者:C++ 模板是鸭子类型的。类层次结构中的实现集不再是明确定义的，因为它可能包含具有相同名称和可能兼容参数的任何函数。你确实记得 Koenig 查找，对吧？

试图将必须具有相同名称的函数列表与真正独立的函数列表分开，这绝对是一场噩梦。在这一点上，您不妨只进行文本搜索和替换。

因此，让我们列出您的 claim /愿望 list :

“减轻无聊的语法”。这只是拖钓，在任何技术意义上都没有任何意义。如果该工具不输入和输出 C++ 语法，则它不是 C++ 重构工具。

“C++ 正在发展”。这意味着这种工具需要花费相当大的费用来维护才能跟上。这也意味着维护良好的工具很容易从较旧的稳定工具中窃取市场份额。这意味着任何工具都需要大量的用户配置——毕竟你不想在 C++03 代码库上生成 C++0x-isms——所以用户将不得不大量使用该工具赢回配置所花费的时间。

“每个 bug 都是一个生存”？不确定这个语法上荒谬的语句到底是什么意思，但也许它意味着零错误容忍度？但这最好通过保持稳定性(涉及多个文件的自动重构的对立面)、可靠的架构和文档(重构工具不会自动更新，或者您是否也想要？)、大量测试套件和静态分析来实现.事实上，如果可能的话，重构使大量测试套件变得更加重要，以验证该工具没有破坏任何东西。请注意，自动静态分析面临一些与重构相同的挑战，但由于它不会更改代码，因此它可以并且确实可以处理后预处理代码和/或编译器 AST。

“减少编译时间”？这是一个没有得到支持的主张，需要一些证据或至少是可靠的推理。您是否期望重构工具为编译防火墙引入 pimpl？ C# 和 Java 风格的重构都不会减少 C++ 编译时间。

“有可能” 不，实际上似乎并非如此。如果你我都不能以一种理智的方式设计一个像 Rename 函数这样的基本重构，更别说正确实现它了，怎么会有人实现几十个呢？如果可能的话，它肯定也是极其昂贵的，这导致:

“这是非常有利可图的”。盈利不仅需要大量愿意为产品付费的用户群，还需要潜在的总销售额超过成本。我声称您严重低估了成本，因此在您对成本和市场进行一些真正的研究之前，我也将其称为一厢情愿的想法。

“它不存在”。在解释了为什么这样的工具不存在之后，我现在要告诉你它已经存在了？是的。至少在重构通过将公共(public)子表达式提升到循环外、展开循环、交换迭代顺序、内联、缓存优化、向量化等操作使最终代码更好的方面，它们已经由优化编译器提供，这是 C++ 领先的领域C# 和 Java 的差距很大。 C++ 根本不需要在 C# 和 Java 中进行许多源代码级别的调整以获得好的最终产品。剩下的只是对源代码的操作，使其更容易被人类访问，现有的工具在这方面做得很好，如果不是异常(exception)的话。