.net - Objective C 真的编译了吗？它不是更像 Visual Basic/.NET 运行时吗？那么是什么阻止它移植到其他平台呢？

Question

在语法上它是 C 的超集。但由于消息是在运行时发送和处理的，这意味着它不能像 c 那样是纯编译语言，但它需要像 Visual Basic 或 .Net 运行时这样的运行时。

那么是什么阻止它通过将此运行时转换为 .NET Framework 或 Java JVM 之类的东西来移植到其他平台？

注意:当我说 VB 时，它当然是编译为字节码的最新版本 6，所以你为什么假装 Java 或 .Net 从根本上不同于 VB6，除了可移植性之外，这是相同的原则:参见 Similar to Java, Visual Basic is编译成称为“字节码”的中间语言。字节码由 Visual Basic 运行时模块翻译成 x86 机器语言。

阅读更多:http://www.answers.com/topic/visual-basic#ixzz19iJd3wjA

与 Java 类似，Visual Basic 被编译成称为“字节码”的中间语言。字节码由 Visual Basic 运行时模块翻译成 x86 机器语言。

Answer 1

您似乎对语言功能的运行时支持需求与 native 编译和 VM 编译(或解释)语言之间的区别感到困惑。

大多数高级语言都需要一些 运行时支持。即使 C 也有一个运行时库，尽管在许多平台上您可以选择不使用其中的一部分或全部。现代操作系统提供了更多的运行时支持，许多语言提供了集成这些的特定于操作系统的扩展——考虑动态加载库……

此外，没有什么能阻止您在本质上不支持它的语言之上构建消息传递系统。由于这是非常普遍的(特别是对于为事件驱动平台编写的程序)，将其集成到语言中可以看作是简单地将一些容易出错的繁琐工作从高级代码中分解出来，并分解到语言和运行时中。

最后，Java 和大多数 .NET 语言实际上都是经过编译的——它们只是编译成字节码，没有任何机器可以本地实现，需要使用虚拟 机器来实际执行它们。性能最高的 VM 在执行代码之前再次编译代码 - 这是一种非常有效的技术，它已被用于 build fast and efficient compiler tool-chains !

Visual Basic 是一个转移注意力的问题 - some versions are interpreted, others are compiled , 和 VB.NET - 与其他 .NET 语言一样 - 被编译为字节码，然后在执行期间再次进行 JIT 编译(虽然表面上相似，但其实现方式往往与早期的 VB VM 非常不同)。如果没有别的，这应该告诉你，一种语言和用它编写的程序的执行方式并不像人们普遍认为的那样紧密耦合......

回答你的最后一个问题:Objective-C 从来都不是不是可移植的，至少在 C 是可移植的意义上(也就是说，source-代码可移植性)。 Apple uses the GCC compiler ，它已被移植到一系列令人眼花缭乱的平台上……但是，一旦您开始利用特定于平台的 API(可能是开始在 Apple 平台上使用 Obj-C 的最佳原因之一……)，您就会重新 limited to platforms that implement those APIs . 二进制可移植性在理论上是可能的，但我知道没有实现。