当使用库时，C / C ++ / Objective-C如何与C＃比较？ [英] How do C/C++/Objective-C compare with C# when it comes to using libraries?

问题描述

此问题基于上一个问题：如何C＃编译需要头文件吗？。

This question is based on a previous question: How does C# compilation get around needing header files?.

确认C＃编译使用多个回合本质上回答了我的原始问题。此外，答案表明，C＃使用存储在程序集中的类型和方法签名元数据在编译时检查代码语法。

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.

Q： C / C ++ / Objective-C如何知道在运行时加载哪些代码在编译时链接？

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，我直观的理解是，某些路径在执行时检查程序集，并且基本上所有的代码都在运行时被加载和动态链接。

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 with C。

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

更新：要澄清，我真正好奇的是C / C ++ / Objective-C编译如何匹配外部定义符号在我的源代码中的实际实现，什么是编译输出，以及基本上如何微处理器执行编译输出以无缝地将控制传递到库代码（就指令指针而言）。我已经用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上，链接器必须提供导入库。一个非常简单的文件，它只声明DLL的名称和DLL中导出的定义的列表。链接器通过在代码中输入跳转并向外部相关性表中添加一条记录来指示跳转位置，从而在运行时对其进行修补，从而解决相关性。加载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.

在托管代码中所有这一切都是在运行时，由JIT编译器驱动。它将IL转换为由程序执行驱动的机器代码。每当代码执行引用另一个类型时，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.

注意的是外部依赖的区别，在构建时可用。 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屋！