swift protocol 见证容器 虚函数表 与 动态派发

一、测试代码:

//protocol DiceGameDelegate: AnyObject {

//}

//

//@objc protocol OcProtocol{

//    @objc func OcFunc()

//}

protocol SeedProtocol {

func NormalFunc()

func ExtenImpFunc()

//@objc func OcFunc()

}

extension SeedProtocol{

func ExtenImpFunc(){}

func ExtenDefineFunc(){}

}

struct NormalStruct:SeedProtocol {

func NormalFunc(){}

}

struct FullImpStruct:SeedProtocol {

func NormalFunc(){}

func ExtenImpFunc(){}

func ExtenDefineFunc(){}

}

struct EmptyStruct {}

extension EmptyStruct:SeedProtocol{

func NormalFunc(){}

}

func CallProtocol(_ object:SeedProtocol)

{

object.NormalFunc()

object.ExtenImpFunc()

object.ExtenDefineFunc()

}

func DoTest(){

CallProtocol(NormalStruct())

//    CallProtocol(FullImpStruct())

//    CallProtocol(EmptyStruct())

}

二、见证容器

  • Existential Container

这是一个最普通的 Existential Container。

  • 前三个word:Value buffer。用来存储Inline的值,如果word数大于3,则采用指针的方式,在堆上分配对应需要大小的内存
  • 第四个word:Value Witness Table(VWT)。每个类型都对应这样一个表,用来存储值的创建,释放,拷贝等操作函数。(管理 Existential Container 生命周期)
  • 第五个word:Protocol Witness Table(PWT),用来存储协议的函数。

用伪代码表示如下:

所以,对于上文代码中的 Point 和 Line 最后的数据结构大致如下:

这里需要注意的几个点:

  • 在 ABI 稳定之前 value buffer 的 size 可能会变,对于是不是 3个 word 还在 Swift 团队还在权衡.
  • Existential Container 的 size 不是只有 5 个 word。示例如下:

对于这个大小差异最主要在于这个 PWT 指针,对于 Any 来说,没有具体的函数实现,所以不需要 PWT 这个指针,但是对于 ProtocolOne&ProtocolTwo 的组合协议,是需要两个 PWT 指针来表示的。

OK,由于 Existential Container 的引入,我们可以将协议作为类型来解决 平凡类型 没有继承的问题,所以 Struct:Protocol 和 抽象类就越来越像了。

https://www.cnblogs.com/feng9exe/p/9680824.html

三、虚函数表:

sil_witness_table hidden NormalStruct: ProtocolCase module ProtocolCase {

method #ProtocolCase.NormalFunc!1: <Self where Self : ProtocolCase> (Self) -> () -> () : @protocol witness for ProtocolCase.ProtocolCase.NormalFunc() -> () in conformance ProtocolCase.NormalStruct : ProtocolCase.ProtocolCase in ProtocolCase // protocol witness for ProtocolCase.NormalFunc() in conformance NormalStruct

method #ProtocolCase.ExtenImpFunc!1: <Self where Self : ProtocolCase> (Self) -> () -> () : @protocol witness for ProtocolCase.ProtocolCase.ExtenImpFunc() -> () in conformance ProtocolCase.NormalStruct : ProtocolCase.ProtocolCase in ProtocolCase // protocol witness for ProtocolCase.ExtenImpFunc() in conformance NormalStruct

}

sil_witness_table hidden FullImpStruct: ProtocolCase module ProtocolCase {

method #ProtocolCase.NormalFunc!1: <Self where Self : ProtocolCase> (Self) -> () -> () : @protocol witness for ProtocolCase.ProtocolCase.NormalFunc() -> () in conformance ProtocolCase.FullImpStruct : ProtocolCase.ProtocolCase in ProtocolCase // protocol witness for ProtocolCase.NormalFunc() in conformance FullImpStruct

method #ProtocolCase.ExtenImpFunc!1: <Self where Self : ProtocolCase> (Self) -> () -> () : @protocol witness for ProtocolCase.ProtocolCase.ExtenImpFunc() -> () in conformance ProtocolCase.FullImpStruct : ProtocolCase.ProtocolCase in ProtocolCase // protocol witness for ProtocolCase.ExtenImpFunc() in conformance FullImpStruct

}

sil_witness_table hidden EmptyStruct: ProtocolCase module ProtocolCase {

method #ProtocolCase.NormalFunc!1: <Self where Self : ProtocolCase> (Self) -> () -> () : @protocol witness for ProtocolCase.ProtocolCase.NormalFunc() -> () in conformance ProtocolCase.EmptyStruct : ProtocolCase.ProtocolCase in ProtocolCase // protocol witness for ProtocolCase.NormalFunc() in conformance EmptyStruct

method #ProtocolCase.ExtenImpFunc!1: <Self where Self : ProtocolCase> (Self) -> () -> () : @protocol witness for ProtocolCase.ProtocolCase.ExtenImpFunc() -> () in conformance ProtocolCase.EmptyStruct : ProtocolCase.ProtocolCase in ProtocolCase // protocol witness for ProtocolCase.ExtenImpFunc() in conformance EmptyStruct

}

四、动态派发机制

// CallProtocol(_:)

sil hidden @ProtocolCase.CallProtocol(ProtocolCase.SeedProtocol) -> () : $@convention(thin) (@in_guaranteed SeedProtocol) -> () {

// %0                                             // users: %8, %5, %2, %1

bb0(%0 : $*SeedProtocol):

debug_value_addr %0 : $*SeedProtocol, let, name "object", argno 1 // id: %1

%2 = open_existential_addr immutable_access %0 : $*SeedProtocol to $*@opened("C73DB366-4AFB-11E9-B4BE-ACBC329BAA1D") SeedProtocol // users: %4, %4, %3

%3 = witness_method $@opened("C73DB366-4AFB-11E9-B4BE-ACBC329BAA1D") SeedProtocol, #SeedProtocol.NormalFunc!1 : <Self where Self : SeedProtocol> (Self) -> () -> (), %2 : $*@opened("C73DB366-4AFB-11E9-B4BE-ACBC329BAA1D") SeedProtocol : $@convention(witness_method: SeedProtocol) <τ_0_0 where τ_0_0 : SeedProtocol> (@in_guaranteed τ_0_0) -> () // type-defs: %2; user: %4

%4 = apply %3<@opened("C73DB366-4AFB-11E9-B4BE-ACBC329BAA1D") SeedProtocol>(%2) : $@convention(witness_method: SeedProtocol) <τ_0_0 where τ_0_0 : SeedProtocol> (@in_guaranteed τ_0_0) -> () // type-defs: %2

%5 = open_existential_addr immutable_access %0 : $*SeedProtocol to $*@opened("C73E23AA-4AFB-11E9-B4BE-ACBC329BAA1D") SeedProtocol // users: %7, %7, %6

%6 = witness_method $@opened("C73E23AA-4AFB-11E9-B4BE-ACBC329BAA1D") SeedProtocol, #SeedProtocol.ExtenImpFunc!1 : <Self where Self : SeedProtocol> (Self) -> () -> (), %5 : $*@opened("C73E23AA-4AFB-11E9-B4BE-ACBC329BAA1D") SeedProtocol : $@convention(witness_method: SeedProtocol) <τ_0_0 where τ_0_0 : SeedProtocol> (@in_guaranteed τ_0_0) -> () // type-defs: %5; user: %7

%7 = apply %6<@opened("C73E23AA-4AFB-11E9-B4BE-ACBC329BAA1D") SeedProtocol>(%5) : $@convention(witness_method: SeedProtocol) <τ_0_0 where τ_0_0 : SeedProtocol> (@in_guaranteed τ_0_0) -> () // type-defs: %5

%8 = open_existential_addr immutable_access %0 : $*SeedProtocol to $*@opened("C73E2738-4AFB-11E9-B4BE-ACBC329BAA1D") SeedProtocol // users: %10, %10

// function_ref SeedProtocol.ExtenDefineFunc()

%9 = function_ref @(extension in ProtocolCase):ProtocolCase.SeedProtocol.ExtenDefineFunc() -> () : $@convention(method) <τ_0_0 where τ_0_0 : SeedProtocol> (@in_guaranteed τ_0_0) -> () // user: %10

%10 = apply %9<@opened("C73E2738-4AFB-11E9-B4BE-ACBC329BAA1D") SeedProtocol>(%8) : $@convention(method) <τ_0_0 where τ_0_0 : SeedProtocol> (@in_guaranteed τ_0_0) -> () // type-defs: %8

%11 = tuple ()                                  // user: %12

return %11 : $()                                // id: %12

} // end sil function ‘ProtocolCase.CallProtocol(ProtocolCase.SeedProtocol) -> ()‘

// DoTest()

sil hidden @ProtocolCase.DoTest() -> () : $@convention(thin) () -> () {

bb0:

%0 = alloc_stack $SeedProtocol                  // users: %9, %8, %7, %4

%1 = metatype $@thin NormalStruct.Type          // user: %3

// function_ref NormalStruct.init()

%2 = function_ref @ProtocolCase.NormalStruct.init() -> ProtocolCase.NormalStruct : $@convention(method) (@thin NormalStruct.Type) -> NormalStruct // user: %3

%3 = apply %2(%1) : $@convention(method) (@thin NormalStruct.Type) -> NormalStruct // user: %5

%4 = init_existential_addr %0 : $*SeedProtocol, $NormalStruct // user: %5

store %3 to %4 : $*NormalStruct                 // id: %5

// function_ref CallProtocol(_:)

%6 = function_ref @ProtocolCase.CallProtocol(ProtocolCase.SeedProtocol) -> () : $@convention(thin) (@in_guaranteed SeedProtocol) -> () // user: %7

%7 = apply %6(%0) : $@convention(thin) (@in_guaranteed SeedProtocol) -> ()

destroy_addr %0 : $*SeedProtocol                // id: %8

dealloc_stack %0 : $*SeedProtocol               // id: %9

%10 = tuple ()                                  // user: %11

return %10 : $()                                // id: %11

} // end sil function ‘ProtocolCase.DoTest() -> ()‘

五、补充说明

Existential Container Layout

Values of protocol type, protocol composition type, or Any type are laid out using existential containers (so-called because these types are "existential types" in type theory).

Opaque Existential Containers

If there is no class constraint on a protocol or protocol composition type, the existential container has to accommodate a value of arbitrary size and alignment. It does this using a fixed-size buffer, which is three pointers in size and pointer-aligned. This either directly contains the value, if its size and alignment are both less than or equal to the fixed-size buffer‘s, or contains a pointer to a side allocation owned by the existential container. The type of the contained value is identified by its type metadata record, and witness tables for all of the required protocol conformances are included. The layout is as if declared in the following C struct:

struct OpaqueExistentialContainer {

void *fixedSizeBuffer[3];

Metadata *type;

WitnessTable *witnessTables[NUM_WITNESS_TABLES];

};

Class Existential Containers

If one or more of the protocols in a protocol or protocol composition type have a class constraint, then only class values can be stored in the existential container, and a more efficient representation is used. Class instances are always a single pointer in size, so a fixed-size buffer and potential side allocation is not needed, and class instances always have a reference to their own type metadata, so the separate metadata record is not needed. The layout is thus as if declared in the following C struct:

struct ClassExistentialContainer {

HeapObject *value;

WitnessTable *witnessTables[NUM_WITNESS_TABLES];

};

Note that if no witness tables are needed, such as for the "any class" type protocol<class> or an Objective-C protocol type, then the only element of the layout is the heap object pointer. This is ABI-compatible with id and id <Protocol> types in Objective-C.

https://github.com/apple/swift/blob/master/docs/ABI/TypeLayout.rst

原文地址:https://www.cnblogs.com/feng9exe/p/10573980.html

时间: 2024-10-08 21:59:00

swift protocol 见证容器 虚函数表 与 动态派发的相关文章

单继承与多继承中的虚函数表和虚函数指针

首先,我们了解一下何为单继承,何为多继承?? 单继承:一个子类只有一个直接父类. 多继承:一个子类有两个或多个直接父类. 单继承中的虚函数表分析: 示例程序: #include <iostream> using namespace std; typedef void(*FUNC)(); class Base { public: virtual void func1() { cout << "Base::func1()" << endl; } virt

C++ 虚函数表解析

转自陈浩的博客 前言 C++中的虚函数的作用主要是实现了多态的机制.关于多态,简而言之就是用父类型的指针指向其子类的实例,然后通过父类的指针调用实际子类的成员函数.这种技术可以让父类的指针有"多种形态",这是一种泛型技术.所谓泛型技术,说白了就是试图使用不变的代码来实现可变的算法.比如:模板技术,RTTI技术,虚函数技术,要么是试图做到在编译时决议,要么试图做到运行时决议. 关于虚函数的使用方法,我在这里不做过多的阐述.大家可以看看相关的C++的书籍.在这篇文章中,我只想从虚函数的实现

C++虚函数表剖析

关键词:虚函数.虚表,虚表指针,动态绑定,多态 一.概述 为了实现C++的多态,C++使用了一种动态绑定的技术. 这个技术的核心是虚函数表(下文简称虚表).本文介绍虚函数表是怎样实现动态绑定的. 二.类的虚表 每一个包括了虚函数的类都包括一个虚表. 我们知道,当一个类(A)继承还有一个类(B)时.类A会继承类B的函数的调用权.所以假设一个基类包括了虚函数,那么其继承类也可调用这些虚函数,换句话说,一个类继承了包括虚函数的基类.那么这个类也拥有自己的虚表. 我们来看下面的代码. 类A包括虚函数vf

C++ 虚函数表解析(转)

转自:http://blog.csdn.net/haoel 前言 C++中的虚函数的作用主要是实现了多态的机制.关于多态,简而言之就是用父类型别的指针指向其子类的实例,然后通过父类的指针调用实际子类的成员函数.这种技术可以让父类的指针有"多种形态",这是一种泛型技术.所谓泛型技术,说白了就是试图使用不变的代码来实现可变的算法.比如:模板技术,RTTI技术,虚函数技术,要么是试图做到在编译时决议,要么试图做到运行时决议. 关于虚函数的使用方法,我在这里不做过多的阐述.大家可以看看相关的C

C++学习之虚函数表及调用规范

在支付工具想做社交,即时通讯工具想做app市场,英语字典想做新闻社交的今天,创造这些怪象的公司要求程序员懂得更多几乎是理所当然的,毕竟现在大家什么都想做.这不,正值招聘季,实验室的几位学长也是一直在讨论各种问题,发现对于C++语言而言,问的最多的还是虚函数表和STL. STL的考点至少是实用的,哪怕要求你读过源码,也并不过分,毕竟知根知底才能更好地应用.但要求程序员掌握对象模型着实拎不清,因为这几乎用不到,远没有在设计模式上投入时间实在,或许它们最希望的是拿批发价招语言专家... 我已经近2年没

类虚函数表原理实现分析(当我们将虚表地址[n]中的函数替换,那么虚函数的实现就由我们来控制了)

原理分析 当调用一个虚函数时, 编译器生成的代码会调用 虚表地址[0](param1, param2)这样的函数. 已经不是在调用函数名了. 当我们将虚表地址[n]中的函数实现改为另外的函数, 虚函数的实现就由我们来控制了. 实验 根据虚表原理, 实验一下修改自己程序的虚函数表项地址. 使编译器生成的代码执行一个虚函数A时, 执行的是我们自己定义的非虚函数B. 知识点 * 使用union赋值, 绕过编译器函数与变量强转赋值的限制 * 类成员函数指针的执行 * 修改和恢复自己的代码段属性 * 虚函

c++ 输出虚函数表内容

class Base{ public: virtual void f(){cout<<"Base::f"<<endl;} virtual void g(){cout<<"Base::g"<<endl;} virtual void h(){cout<<"Base::h"<<endl;} }; typedef void (*Fun)(void); int main(){ Base

C++中3种多态实现机制之虚函数表

上期我们简单的讲解了利用RTTI来实现多肽,这期我们就来聊聊利用虚函数的方法来实现多肽. 1.什么是虚函数 在某基类中声明为 virtual 并在一个或多个派生类中被重新定 义的成员函数,用法格式为:virtual 函数返回类型 函数名(参数表) {函数体}:,实现多态性,通过指向派生类的基类指针或引用,访问派生类中同名覆盖成员函数 2.实现多肽的条件 简单的说就是:基类的指针或引用指向子类对象,当子类中成员函数和基类成员函数:函数名相同,参数列表相同,返回值相同,并且基类该函数为虚函数时,基类

《COM原理与应用》题外话——C++虚函数表和delete this

delete this看起来非常的奇怪,我记得在<C++ Primer>中提到过delete this,但是我已经忘了在哪了,也一直没有找到(因为没有电子版,所以一直没找到~).<C++ Primer>中提到的是在析构函数中使用delete this会造成析构函数的无限调用,最终造成栈溢出.我也在网上看了一些,很多人觉得不该使用delete this,因为会引起一些问题.但是delete this也挺有用处的,就和goto语句一样,不应该被一棍子打死(goto语句其实怪好用的:-D