c# - 为什么虚拟方法被认为是早期绑定(bind)？

Question

绑定(bind)的一个定义是，它是用内存地址替换函数名的行为。

a) 因此我假设早期绑定(bind)意味着函数调用在编译过程中被替换为内存地址，而对于后期绑定(bind)，这种替换发生在运行时？

b) 为什么虚拟方法也被认为是早期绑定(bind)(因此目标方法在编译时找到，并创建调用此方法的代码)？据我所知，对于虚拟方法，对实际方法的调用仅在运行时而不是编译时解析？!

谢谢

编辑:

1)

A a=new A();
a.M();

据我所知，在编译时并不知道运行时将在堆上的哪个位置(因此在哪个内存地址)创建实例 a。现在，通过早期绑定(bind)，函数调用在编译过程中被替换为内存地址。但是编译器如何用内存地址替换函数调用，如果它不知道在堆上的哪个位置将在运行时创建对象 a (这里我假设方法的地址 a.M 也将与 a 位于相同的内存位置)？

2)

v-table calls are neither early nor late bound. Instead there's an offset into a table of function pointers. The offset is fixed at compile time, but which table the function pointer is chosen from depends on the runtime type of the object (the object contains a hidden pointer to its v-table), so the final function address is found at runtime.

但假设 T 类型的对象是通过反射创建的(因此应用程序甚至不知道类型 T 的存在)，那么在编译时如何存在该类型对象的入口点？

Answer 1

后期绑定(bind)

对于后期绑定(bind)，您所拥有的只是方法的名称。在编译时，您无法知道该方法是否存在。这在 Ruby 或 Python 等语言中称为“鸭子类型”。

后期绑定(bind)很慢，因为您必须按名称查找函数。这也很危险，因为您无法避免出现小的拼写错误。

在版本 4 之前，除了显式调用反射 API 之外，C# 不支持后期绑定(bind)。

早期绑定(bind)

使用早期绑定(bind)时，您将根据实际方法进行编译。这个方法可以直接引用，也可以是V表中的slot。无论哪种方式，您都保证不会抛出 MissingMethod 异常。

历史

Visual Basic 以支持早期绑定(bind)和后期绑定(bind)而闻名，但由于其其他限制，它从未被视为真正的动态语言。同时，7(又名 VB.NET)之前的版本对强制早期绑定(bind)的支持非常差，因此也很难将其称为静态语言。

在 .NET 4 中，可以说 C# 和 VB 都提供了静态和动态类型语言所期望的大部分功能。

有一次，Java 被错误地称为具有后期绑定(bind)支持，而实际上它只有早期绑定(bind)、OOP 风格的 V 表。多年来，这引起了相当多的困惑。