尽管你们所有的专家都发表了意见,但我完全不同意重构支持问题与 C + + 语言语义或任何语言语义有关的观点。除了编译器构建器本身没有选择实现一个在第一种情况下,由于他们自己的原因或约束他们可能。
我不想冒犯你,但是我很抱歉地说 jsb 先生,你提供的上面的链接支持你的案例(比如 Yosefk)关于 C + + 缺陷是完全没有问题的。这更像是当有人问“旧金山”时,你为“洛杉矶”提供方向。
在我看来,对某些语言提出重构难度问题更像是对语言完整性本身提出质疑。特别是对于那些有时只是痛苦的语言来说。当涉及到它们的变量声明和使用时。好吧!告诉我,你怎么会在一棵节点树里找不到一个节点呢?所以它对任何语言的作用就像机器级代码一样简单。你知道你 VS 编译器可以很容易地检测一些变量或例程是死代码。明白我的意思了吗?
而且确保它与 IDE 用于所有类似目的的数据库几乎相同。以前,编译器只是一个单独的实体,IDE 只是一个带有一些专门化的文本编辑器,但随着时间的推移,编译器和 IDE 编辑器之间的差距变得越来越小,它直接开始在类似的解析数据库上工作。这使得更有效地处理所有这些智能感知和重构或其他语法相关问题成为可能。对于所有的预编译工作和 JIT 编译来说,这个差距几乎是忽略不计的。因此,使用同一个数据库实现这两个目的几乎是有意义的,否则由于复制,内存需求会更高。
你们都是程序员-我不是!你们似乎很难想象重构是如何在 C + + 或任何我不能理解的语言中实现的。这只是为了一些事情,你必须付出更多的努力,少一些取决于多重的人,你试图推。
通过使用允许访问其中间格式的编译器(Clang + LLVM) ,Google 重构了整个1亿行 C + + 代码库。
底线是,第三方在这里搞砸了,没有现实的方法让他们重构 VS C + + ,除非 MS 以同样的方式输出中间结果。如果你从编程问题的角度来看,这是显而易见的: 为了重构 VS C + + ,你必须能够用 VS 编译 C + + 的完全相同的方式来处理相同的 bug、限制、缺陷、黑客攻击、快捷方式、变通方法等等。通常的嫌疑人像科德鲁什和 Resharper 没有预算为这种疯狂虽然显然他们正在努力,但它已经多年..。