备选虚拟机制实现? [英] Alternative virtual mechanism implementations?

查看:99
本文介绍了备选虚拟机制实现?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

C ++支持通过虚拟机制的动态绑定。但是据我所知,虚拟机制是编译器的实现细节,标准只是指定在特定情况下应该发生什么的行为。大多数编译器通过虚拟表和虚拟指针实现虚拟机制。是的,我知道这是如何工作的,所以我的问题不是关于虚拟指针和表的实现细节。我的问题是:

C++ supports dynamic binding through virtual mechanism. But as I understand the virtual mechanism is an implementation detail of the compiler and the standard just specifies the behaviors of what should happen under specific scenarios. Most compilers implement the virtual mechanism through the virtual table and virtual pointer. And yes I am aware of how this works, So my question is not about implementation detail of virtual pointers and table. My questions are:


  1. 是否有任何编译器以虚拟指针和虚拟表机制以外的其他方式实现虚拟机制?就我所见过的大多数(读g ++,Microsoft visual studio)通过虚拟表,指针机制实现它。

  2. 只要一个虚函数的任何类的 sizeof 因此,由于虚拟ptr和tbl机制本身是编译器实现,我将在上面做的这个语句总是真的?

  1. Are there any compilers which implement Virtual Mechanism in any other way other than the virtual pointer and virtual table mechanism? As far as i have seen most(read g++,Microsoft visual studio) implement it through virtual table, pointer mechanism. So practically are there any other compiler implementations at all?
  2. The sizeof of any class with just a virtual function will be size of an pointer (vptr inside this) on that compiler, So given that virtual ptr and tbl mechanism itself is compiler implementation, will this statement I made above be always true?


推荐答案

对象中的vtable指针总是最高效的。我的编译器为另一种语言使用类似的原因,但不再是使用对象指针:它使用一个单独的数据结构,映射对象地址到所需的元数据:在我的系统中,这恰好是形状信息使用

It is not true that vtable pointers in objects are always the most efficient. My compiler for another language used to use in-object pointers for similar reasons but no longer does: instead it uses a separate data structure which maps the object address to the required meta-data: in my system this happens to be shape information for use by the garbage collector.

这个实现为单个简单对象花费了更多的存储空间,对于具有多个基础的复杂对象更有效,并且 对数组更有效,因为在数组中所有对象的映射表中只需要一个条目。我的特定实现也可以找到元数据给指向对象内部任何点的指针。

This implementation costs a bit more storage for a single simple object, is more efficient for complex objects with many bases, and it is vastly more efficient for arrays, since only a single entry is required in the mapping table for all objects in the array. My particular implementation can also find the meta-data given a pointer to any point interior to the object.

实际的查找非常快,存储要求非常适中,因为我在地球上使用最好的数据结构:Judy数组。

The actual lookup is extremely fast, and the storage requirements very modest, because I am using the best data structure on the planet: Judy arrays.

我也知道没有C ++编译器使用vtable指针,但它不是唯一的办法。事实上,带有基础的类的初始化语义使得任何实现变得凌乱。这是因为完成类型必须在构建对象时看到。作为这些语义的结果,复杂的mixin对象导致生成大量的vtables集合,大对象和缓慢的对象初始化。这可能不是vtable技术的结果,因为需要严格遵循子对象的运行时类型在任何时候都是正确的要求。实际上,在构建期间没有什么好的理由,因为构造函数不是方法,不能明智地使用虚拟分派:这对我来说不是那么清楚,因为析构函数是真正的方法。

I also know of no C++ compiler using anything other than vtable pointers, but it is not the only way. In fact, the initialisation semantics for classes with bases make any implementation messy. This is because the complete type has to see-saw around as the object is constructed. As a consequence of these semantics, complex mixin objects lead to massive sets of vtables being generated, large objects, and slow object initialisation. This probably isn't a consequence of the vtable technique as much as needing to slavishly follow the requirement that the run-time type of a subobject be correct at all times. Actually there's no good reason for this during construction, since constructors are not methods and can't sensibly use virtual dispatch: this isn't so clear to me for destruction since destructors are real methods.

这篇关于备选虚拟机制实现?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆