如何C / C ++ / Objective-C的用C＃进行比较，当涉及到使用库？ [英] How do C/C++/Objective-C compare with C# when it comes to using libraries?

问题描述

这个问题是基于previous问题：<一href=\"http://stackoverflow.com/questions/1917935/how-does-c-compilation-get-around-needing-header-files\">http://stackoverflow.com/questions/1917935/how-does-c-compilation-get-around-needing-header-files.

This question is based on a previous question: http://stackoverflow.com/questions/1917935/how-does-c-compilation-get-around-needing-header-files.

的确认C＃编译利用多道基本上回答我原来的问题。此外，答案表明，C＃使用存储在装配在编译时检查code语法类型和方法签名的元数据。

Confirmation that C# compilation makes use of multiple passes essentially answers my original question. Also, the answers indicated that C# uses type and method signature metadata stored in assemblies to check code syntax at compile time.

问：如何C / C ++ / Objective-C的知道什么code。在这是在编译时链接运行时加载？并将其绑到一个技术我很熟悉，请问C＃/ CLR做到这一点？

Q: how does C/C++/Objective-C know what code to load at run time that was linked at compile-time? And to tie it into a technology I'm familiar with, how does C#/CLR do this?

纠正我，如果我错了，但对于C＃/ CLR，我直观的理解是，某些路径检查在执行时组件，基本上所有code被加载并在运行时动态链接。

Correct me if I'm wrong, but for C#/CLR, my intuitive understanding is that certain paths are checked for assemblies upon execution, and basically all code is loaded and linked dynamically at run time.

编辑：更新以包括C ++和Objective-C用C

Updated to include C++ and Objective-C with C.

更新：：要澄清，我真的很好奇的是如何C / C ++ / Objective-C的编译我的源代码相匹配的外部定义符号与实际实现，$ C $的C，什么是编译输出，基本上如何编译输出由微处理器执行无缝地通过控制进库code（在指令指针而言）。我这样做的CLR虚拟机，但我很想知道这是如何工作的概念C ++ / Objective-C的一个实际的微处理器。

Update: To clarify, what I really am curious about is how C/C++/Objective-C compilation matches an "externally defined" symbol in my source with the actual implementation of that code, what is the compilation output, and basically how the compilation output is executed by the microprocessor to seamlessly pass control into the library code (in terms of instruction pointer). I have done this with the CLR virtual machine, but am curious to know how this works conceptually in C++/Objective-C on an actual microprocessor.

推荐答案

链接器起着C / C ++构建解决外部依赖的重要作用。 .NET语言不使用连接器。

The linker plays an essential role in C/C++ building to resolve external dependencies. .NET languages don't use a linker.

有两种外部依赖的，那些实现可在输入到连接器提供了另一个.OBJ或.LIB文件链接的时间。而那些在另一个可执行模块使用。在Windows中的DLL。

There are two kinds of external dependencies, those whose implementation is available at link time in another .obj or .lib file offered as input to the linker. And those that are available in another executable module. A DLL in Windows.

链接器解析在链接时首当其冲，没有什么复杂的，因为发生在连接器会知道依赖的地址。后者步骤是高度依赖于平台。在Windows中，连接器必须提供与导入库。一个pretty简单的文件，仅仅声明DLL的名称和DLL导出的定义列表。链接器解析输入在code跳又增加一个记录到外部依赖表指示跳转位置，以便它可以在运行时进行修补的依赖。 DLL和设置导入表的装载在运行时由Windows加载程序完成。这是这个过程的一个鸟瞰，有很多无聊的细节，使这是迅速发生越好。

The linker resolves the first ones at link time, nothing complicated happens since the linker will know the address of the dependency. The latter step is highly platform dependent. On Windows, the linker must be provided with an import library. A pretty simple file that merely declares the name of the DLL and a list of the exported definitions in the DLL. The linker resolves the dependency by entering a jump in the code and adding a record to the external dependency table that indicates the jump location so that it can be patched at runtime. The loading of the DLL and setting up the import table is done at runtime by the Windows loader. This is a bird's-eye view of the process, there are many boring details to make this happen as quickly as possible.

在管理code所有这一切都在运行时完成的，由JIT编译器驱动。它转换成IL机code，通过执行程序来​​驱动。每当code执行引用另一种类型，JIT编译器弹簧付诸行动，加载的类型和转换的类型调用的方法。装载类型的副作用加载包含类型的程序集，如果没有之前加载。

In managed code all of this is done at runtime, driven by the JIT compiler. It translates IL into machine code, driven by program execution. Whenever code executes that references another type, the JIT compiler springs into action, loads the type and translates the called method of the type. A side-effect of loading the type is loading the assembly that contains the type, if it wasn't loaded before.

值得注意的太是可用在构建时的外部依赖的差异。 A C / C ++编译器编译一个源文件的时间，依赖关系由链接器解决。一个托管的编译器通常会将创造的组件，输入而不必将它们编译一次一个的所有源文件。独立的编译和链接实际上是在支持（.netmodule和Al.exe工具使用），但没有很好地使用工具的支持，因而很少这样做。此外，它不能支持像扩展方法和局部类的功能。因此，管理的编译器需要更多的系统资源来完成这项工作。一应俱全的现代化的硬件。建立了C / C ++编译过程在这样一个时代，这些资源是不可用的。

Notable too is the difference for external dependencies that are available at build time. A C/C++ compiler compiles one source file at a time, the dependencies are resolved by the linker. A managed compiler normally takes all source files that create an assembly as input instead of compiling them one at a time. Separate compilation and linking is in fact supported (.netmodule and al.exe) but is not well supported by available tools and thus rarely done. Also, it cannot support features like extension methods and partial classes. Accordingly, a managed compiler needs many more system resources to get the job done. Readily available on modern hardware. The build process for C/C++ was established in an era where those resources were not available.

这篇关于如何C / C ++ / Objective-C的用C＃进行比较，当涉及到使用库？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！