目标C真的被编译了吗？它不是更像Visual / .NET运行时吗？那么，是什么使它不能移植到其他平台呢？

Question

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

那么，通过将这个运行时转换为类似.NET框架或Java之类的东西，有什么可以阻止它移植到其他平台呢？

注意:当我说VB时，它当然是最后一个版本6，它编译成字节码，那么为什么要假装.Net或VB6与VB6有根本的不同--除了可移植性--这是相同的原则:参见类似于Java，Visual被编译成一种名为“字节码”的中间语言。字节码通过Visual运行时模块转换为x86机器语言。

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

与类似，Visual被编译成一种名为“字节码”的中间语言。字节码通过Visual运行时模块.翻译成机器语言。

Answer 1

它根本不遵循不能编译消息传递的结论。这仅仅意味着消息必须在运行时解析为方法调用。目标-C当然是一种汇编语言.

该过程被描述为这里。对方法的初始调用确实比C++方法调用慢，但是解析是缓存的，因此后续调用更快。这种不确定的行为将使客观C不适合某些应用。

目的-C作为GCC的前端，具有高度的便携性.然而，只有OSX及其前身NextSTEP和iOS有一个Objective为首选语言的OSX(即OSX是用/为之编写的语言)。因此，尽管它可以在任何支持GCC的操作系统上使用，但它在此类平台上的用处有限。

Answer 2

您似乎混淆了对语言特性的运行时支持的需求，以及本机编译语言和VM编译(或解释)语言之间的区别。

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

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

最后，Java和大多数.NET语言都是实际编译的--它们只是编译成没有机器本地实现的字节码，需要使用虚拟机来实际执行它们。在执行代码之前，最具表现力的VM会再次编译代码--这可能是一种非常有效的技术，以至于它已经被用于构建快速高效的编译工具链！

Visual在这里是个麻烦-- 一些版本被解释，另一些版本被编译。和VB.NET --类似于其他.NET语言--被编译成字节码，然后JIT在执行过程中再次编译(虽然表面上类似，但它的实现往往与早期的VB非常不同)。如果没有别的，这应该会告诉您，一种语言和用它编写的程序的执行方式并不像人们普遍认为的那样紧密耦合.

在回答您的最后一个问题：Objective从来都不是可移植的，至少在C是可移植的意义上(也就是说，源代码的可移植性)。苹果公司使用GCC编译器，它已经移植到一系列令人眼花缭乱的平台上.但是，一旦您开始利用特定于平台的API(可能是在Apple平台上使用Obj的最佳原因之一)你是仅限于实现这些APIs的平台。。从理论上讲，二进制可移植性是可能的，但我知道没有实现。

Answer 3

但是，由于消息是在运行时发送和处理的，这意味着是一种纯编译语言，如c。

为什么不呢？您可以用编译语言发送和处理消息，如果需要的话，编译语言也可以提供反射和动态分派调用。

在OSX/iOS上实现的Obj被编译成本机代码。下面是对Obj运行时的一个小介绍，下面是另一个