4

我注意到一些不太古老的 VM 语言，例如用 C 编写的 Lua、NekoVM 和 Potion。

看起来他们正在重新实现许多 C++ 特性。

用 C 而不是 C++ 编写它们有什么好处吗？

4

9 回答 9

23

我对 Lua 有所了解。

  • Lua 是用纯 ANSI 标准 C 编写的，可以在任何 ANSI 平台上编译，没有错误和警告。因此，Lua 几乎可以在世界上任何平台上运行，包括佳能 PowerShot 相机之类的平台。让 C++ 在奇怪的小型嵌入式平台上运行要困难得多。

  • Lua 是一个高性能 VM，由于 C 不能表达方法调用（可能是虚拟的，也可能不是）和运算符重载，因此仅通过查看代码就更容易预测 C 代码的性能。C++，尤其是模板库，使得在不知不觉中烧毁资源有点太容易了。（Lua 的完整实现不仅包括 VM，还包括库，适合 145K 的 x86 目标代码。整个语言甚至适合一个很小的 ​​256K 缓存，你可以在 Intel i7 上的 L2 和旧芯片上的 L1 中找到它。除非你真的知道什么你正在做，编写编译成这么小的东西的 C++ 要困难得多。）

这是用 C 编写 VM 的两个很好的理由。

于 2009-04-23T02:30:51.157 回答
6

看起来他们正在重新实现许多 C++ 特性。

您是否建议在 C++ 中实现多态性比在 C 中更容易？我认为你大错特错了。

如果你用 C++ 编写一个 VM，你就不会根据 C++ 的多态性来实现多态性。您将推出自己的虚拟表，将函数名称映射到指针或类似的东西。

于 2009-04-23T02:56:55.587 回答
5

人们习惯了 C。我不得不承认，我更有可能为自己的项目编写 C，即使我从 cfront 1.0 开始就一直在编写 C++。

如果您想完全控制事物，C 会更容易一些。

于 2009-04-23T02:01:10.120 回答
5

一个明显的答案是互操作性。任何时候语言 X 必须调用在语言 Y 中定义的函数，您通常要确保 X 或 Y 是 C（即语言 C）

C++ 没有定义 ABI，因此从另一种语言调用 C++ 代码在可移植性方面有点棘手。但是调用 C 代码几乎是微不足道的。这意味着您的虚拟机的至少一部分可能必须用 C 编写，那么为什么不保持一致并用 C 编写整个东西呢？

C的另一个优点是它很简单。每个人都可以阅读它，并且有很多程序员可以帮助您编写它。无论好坏，C++ 更像是一种专家语言。你可以用 C++ 做很多令人印象深刻的事情，它可以为你节省很多工作，但真正擅长它的程序员也很少。

于 2009-04-23T02:43:09.177 回答
3

在 C++ 中“精通”要困难得多，在精通 C++ 之前，他们会遇到很多错误和问题。现在，尤其是在与很多人一起处理大型项目时，其中一个不够好的机会要大得多，因此用 C 编写项目通常风险较小。还有可移植性问题 - C 代码比 C++ 更容易跨编译器移植。

于 2009-04-23T02:11:27.693 回答
3

Lua 还有很多在 Lisp 中很容易实现的特性，那为什么不以此为基础呢？关键在于，C 语言只不过是经过美化的汇编代码，只有一层薄薄的抽象。它就像一块经过打磨的白板，您可以在其上构建更高级别的抽象。C++就是这样一个建筑。Lua 是一个不同的建筑，如果它必须使用 C++ 抽象，它就必须围绕现有的 C++ 结构弯曲它的意图。相反，从白板开始，您可以自由地按照自己的意愿构建它。

于 2009-04-23T13:27:41.047 回答
0

C++ 是用 C 实现的。我怀疑每个人都在遵循 C++ 方法。

尽管现代 C++ 编译器跳过（或隐藏）显式 C++ 到 C 的转换作为一个离散步骤，但 C++ 语言具有源于底层 C 实现的特性。

两个例子。

  • 除了引用之外的指针完全是因为 C。引用就足够了，这就是 Java、Python 和 Ruby 的工作方式。

  • 这些类不是运行时存在的一流对象，因为类只是在底层 C 代码中定义属性和方法函数的一种方式。类对象在 Java、Python 和 Ruby 中运行时存在，并且可以被操作。

于 2009-04-23T02:00:37.127 回答
0

在许多情况下，C 中的代码可能比 C++ 快得多。例如，stdio.c 库中的大多数函数都比 iostream 快。scanf 比 cin 快， printf 比 cout 快等。

并且 VM 需要高性能，因此 C 代码非常有意义，尽管程序很可能需要更长的时间来开发。

于 2009-04-23T02:35:48.740 回答
0

顺便说一句，您应该查看 CLR（Rotor-incarnation）和 Java 源代码，您会注意到它更像是 C++-as-C，而不是现代或好的 C++。所以它在那里有一个相似之处，它是对玩具进行抽象并使其平均性能对托管语言中的人群感到满意的副作用。

它还有助于避免天真的 C++ 使用的陷阱。例外情况和所有其他类型的事情（大卫在 boost 咨询中开始工作等等，而我们在他还没有工作之前就构建了音序器和音频采样 :) 也是一个问题。

Python 集成是另一回事，例如，在 boost 方面有一段混乱的历史。但是对于原始数据类型和接口/互操作和机器抽象，很明显没有什么比 C 更好。也没有编译器问题，它仍然引导很多东西在你得到任何有影响力的东西之前/曾经/将要。

Stepanov 在完成 STL 时就认识到了这一成就，而 Bjarne 则通过模板实现了这一成就。这三件事总是值得考虑的，因为在流行的托管语言中它们没有像样的化身，而不是那种表现力和力量。所有这一切都在 20 多年后，这是了不起的，并且仍然通过 C/C++ 引导。善良的遗产（但我并不是在为“黑暗时代”C 代码 c1982-2000 辩护，只是这个想法，你可以滥用任何东西）。

于 2009-04-23T22:34:33.293 回答