Objective C 真的是编译过的吗？它不是更像 Visual Basic / .NET 运行时吗？那么是什么阻碍了它移植到其他平台呢？
从语法上讲，它是 C 的超集。但由于消息是在运行时发送和处理的，这意味着它不能是像 c 这样的纯编译语言，但它需要像 Visual Basic 或 .Net 运行时这样的运行时。
那么，是什么阻止了通过将此运行时转换为 .NET Framework 或 Java JVM 之类的东西来将其移植到其他平台呢？
注意：当我说 VB 时，它当然是编译为字节码的最新版本 6，所以为什么你假装 Java 或 .Net 与 VB6 根本不同，除了可移植性之外，它的原理相同：请参阅与 Java 类似，Visual Basic 被编译为中间语言称为“字节码”。字节码由 Visual Basic 运行时模块翻译成 x86 机器语言。
了解更多：http://www.answers.com/topic/visual-basic#ixzz19iJd3wjA< /a>
与 Java 类似，Visual Basic 被编译成一种称为“字节码”的中间语言。字节码由 Visual Basic 运行时模块翻译成 x86 机器语言。
Syntactically it's superset of C. But since messages are sent and processed at runtime this means it cannot be a pure compiled language like c but it needs a runtime like Visual Basic or .Net runtime.
Then what prevents it to be portable to other platforms by transforming this runtime to something like .NET Framework or Java JVM ?
Note: when I say VB it's of course last version 6 which compiles to Bytecode so why do you pretend that Java or .Net are different fundamentally from VB6 except for portability it's the same principle: see Similar to Java, Visual Basic is compiled into an intermediate language called "bytecode." The bytecode is translated into x86 machine language by the Visual Basic runtime module.
Read more: http://www.answers.com/topic/visual-basic#ixzz19iJd3wjA
Similar to Java, Visual Basic is compiled into an intermediate language called "bytecode." The bytecode is translated into x86 machine language by the Visual Basic runtime module.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您似乎对语言功能的运行时支持的需求以及本机编译和 VM 编译（或解释）语言之间的差异感到困惑。
大多数高级语言需要某种运行时支持。即使 C 也有一个运行时库，尽管在许多平台上您可以选择不使用其中的部分或全部。现代操作系统提供了更多的运行时支持，并且许多语言提供了集成这些的特定于操作系统的扩展 - 考虑动态加载库......
此外，没有什么可以阻止您在不支持的语言之上构建消息传递系统 。本质上不支持它。由于这是非常常见的（特别是对于为事件驱动平台编写的程序），因此将其集成到语言中可以被视为简单地将一些容易出错的繁忙工作从高级代码中分解到语言和运行时中。
最后，Java 和大多数 .NET 语言实际上都是编译的 - 它们只是编译为没有机器本机实现的字节码，需要使用虚拟机来实际执行它们。性能最高的虚拟机在执行代码之前再次编译代码 - 这是一种非常有效的技术，已被用于构建快速高效的编译器工具链！
Visual Basic 在这里是一个转移注意力的东西 - 某些版本被解释，其他版本被编译，并且VB.NET - 与其他 .NET 语言一样 - 被编译为字节码，然后在执行期间再次进行 JIT 编译（虽然表面上相似，但其实现方式往往与早期的 VB VM 非常不同）。如果不出意外，这应该告诉您一种语言和用它编写的程序的执行方式并不像人们普遍认为的那样紧密耦合......
回答你的最后一个问题：目标-C 从来都不是可移植的，至少在 C 是可移植的意义上（也就是说，源代码可移植性）。 Apple 使用 GCC 编译器，它已被移植到一系列令人眼花缭乱的平台上......但是，一旦您开始利用特定于平台的 API（可能是在 Apple 平台上使用 Obj-C 的最佳原因之一......），您就仅限于实现这些 API 的平台。理论上，二进制可移植性是可能的，但据我所知还没有实现。
You appear to be confused between the need for runtime support for language features, and the difference between a native-compiled and VM-compiled (or interpreted) language.
Most high-level languages need some sort of run-time support. Even C has a run-time library, although on many platforms you can choose not to use some or all of it. Modern operating systems provide even more runtime support, and many languages provide OS-specific extensions that integrate these - consider dynamic loading of libraries...
Furthermore, there's nothing stopping you from building a message-passing system on top of a language that doesn't support it intrinsically. Since this is extremely common (especially for programs written for event-driven platforms), integrating it into the language can be looked at as simply factoring some error-prone busywork out of the high-level code and into the language and runtime.
Finally, both Java and most .NET languages are actually compiled - they just compile down to a bytecode that no machine implements natively, requiring the use of a Virtual Machine to actually execute them. The most performant VMs compile the code again prior to executing it - this can be such an effective technique that it has been used to build fast and efficient compiler tool-chains!
Visual Basic is a red herring here - some versions are interpreted, others are compiled, and VB.NET - like other .NET languages - is compiled to bytecode and then JIT-compiled again during execution (while superficially similar, this tends to be implemented very differently from the earlier VB VMs). If nothing else, this should tell you that a language and the means by which programs written in it are executed are not as tightly coupled as is commonly-believed...
In answer to your last question: Objective-C has never not been portable, at least in the sense that C is portable (that is to say, source-code portability). Apple uses the GCC compiler, which has been ported to a dizzying array of platforms... However, once you start taking advantage of platform-specific APIs (probably one of the best reasons for using Obj-C on Apple platforms to begin with...) you're limited to platforms that implement those APIs. Binary portability is possible in theory, but I know of no implementations.
这并不意味着消息传递不能被编译。它仅仅意味着消息必须在运行时解析为方法调用。 Objective-C 无疑是一种编译语言。
此处描述了该过程。确实，对方法的初始调用比 C++ 方法调用慢，但解析结果被缓存，因此后续调用速度更快。这种不确定性行为会使 Objective-C 不适合某些应用程序。
Objective-C 作为 GCC 的前端提供，因此具有高度可移植性。然而，只有 OSX 及其前身 NextSTEP 和 iOS 具有 OS API，其中 Objective-C 是首选语言（即编写 OS API 的语言）。因此，虽然它可以在任何支持 GCC 的操作系统上使用，但它在此类平台上的用处是有限的。
It does not follow at all that message passing cannot be compiled. It merely implies that the message must be resolved to a method call at runtime. Objective-C is certainly a compiled language.
The process is described here. It is true that the initial call to a method is slower than a C++ method call, but the resolution is cached so subsequent calls are faster. Such non deterministic behaviour would make Objective-C unsuited to some applications.
Objective-C is provided as a front-end for GCC, so is highly portable. However only OSX and its predecessor NextSTEP, and iOS have an OS API for which Objective-C is the preferred language (i.e. the language the OS API is written in/for). So while it can be used on any OS that supports GCC, its usefulness on such platforms is limited.
为什么不呢？您可以使用编译语言发送和处理消息，编译语言还可以提供反射和动态分派调用（如果需要）。
在 OSX/iOS 上实现的 Obj-C 被编译为本机代码。 这里是对 Obj-C 运行时的一个小介绍， 这是另一个
Why not ? You can send and process messages in a compiled language, a compiled language could provide reflection and dynamically dispatch calls as well, if that would be needed.
Obj-C, as implemented on OSX/iOS is compiled to native code. Here's a small introduction to the Obj-C runtime, here's another