观察itable的结构，首先是描述type信息的一些元数据，然后是满足Stringger接口的函数指针列表（注意，这里不是实际类型Binary的函数指针集哦）。因此我们如果通过接口进行函数调用，实际的操作其实就是s.tab->fun[0](s.data) 。是不是和C++的虚表很像？但是他们有本质的区别。先看C++，它为每个类创建了一个方法集即虚表，当子类重写父类的虚函数时，就将表中的相应函数指针改为子类自己实现的函数，如果没有则指向父类的实现，当面临多继承时，C++对象结构里就会存在多个虚表指针，每个虚表指针指向该方法集的不同部分。我们再来看golang的实现方式，同C++一样，golang也为每种类型创建了一个方法集，不同的是接口的虚表是在运行时专门生成的，而c++的虚表是在编译时生成的（但是c++虚函数表表现出的多态是在运行时决定的).例如，当例子中当首次遇见s := Stringer(b)这样的语句时，golang会生成Stringer接口对应于Binary类型的虚表，并将其缓存。那么为什么go不采用c++的方式来实现呢？这根c++和golang的对象内存布局是有关系的。
首先c++的动态多态是以继承为基础的，在对象构造初始化的时首先会初始化父类，其次是子类，也就是说一个对象的内存布局是虚表，父类部分，子类部分（编译器不同可能会有差异），当一个父类指针指向子类时，会发生内存的截断，截断子类部分(内存地址偏移)，但是此时子类的虚表中的函数指针实际上还是指向了自己的实现，所以此时的指针才会调用到子类的虚函数，如果不是虚函数，因为内存已经截断没有子类的非虚函数信息了，所以只能调用父类的了，这种继承关系让c++的虚表的初始化非常清晰，在一个对象初始化时先调用父类的构造此时虚表跟父类是一样的，接下来初始化子类，此时编译器就会去识别子类有没有覆盖父类的虚函数，如果有则虚表中相应的函数指针改成自己的虚函数实现指针。
那么go有什么不同呢，首先我们很清楚go是没有严格意义上的继承的，go的接口不存在继承关系，只要实现了接口定义的方法都可以成为接口类型，这给go的虚表初始化带来很大的麻烦，到底有多少类型实现了这个接口，一个类型到底实现了多少接口这让编译器很confused。举个例子，某个类型有m个方法，某接口有n个方法，则很容易知道这种判定的时间复杂度为O(mXn)，不过可以使用预先排序的方式进行优化，实际的时间复杂度为O(m+n)这样看来其实还行那为什么要在运行时生成虚表呢，这不是会拖慢程序的运行速度吗，注意我们这里是某个类型，某个接口，是1对1的关系，如果有n个类型，n个接口呢，编译器难道要把之间所有的关系都理清吗？退一步说就算编译器任劳任怨把这事干了，可是你在写过程中你本来就不想实现那个接口，而你无意中给这个类型实现的方法中包含了某些接口的方法，你根本不需要这个接口(况且go的接口机制会导致很多这种无意义的接口实现)，你欺负编译器就行了，这也太欺负人了吧。如果我们放到运行时呢，我们只要在需要接口的去分析一下类型是否实现了接口的所有方法就行了很简单的一件事。
