Explore the underlying implementation of C + + and go interfaces

This is a creation in Article, where the information may have evolved or changed.

1. "Interface" in C + +

C + + does not have a clear "interface", the general convention inherits a class, has reached the interface of "implementation."

First, let's take a look at the single inherited memory layout (<font color= Crimson size=4> relies on the actual implementation of each vendor, which is illustrated only by the Microsoft implementation example. Thanks for the strongest IDE in the universe. </font>)

Its polymorphism is mainly implemented by the virtual function table (VFPTR): When a pointer or reference calls a virtual function, it is determined at run time by the object's virtual function table + function declaration order to which function to bind to

class IDuck {public:              //嘎嘎地叫        virtual void GaGaSpeaking() = 0;                 //老爷的官步        virtual void OfficialWalking() = 0;          private:              unsigned int height;};class DonaldDuck : public IDuck { public:             void GaGaSpeaking() {               std::cout << "DonaldDuck Speak" << std::endl;        }                 void OfficialWalking() {               std::cout << "DonaldDuck Walk" << std::endl;       }     };int main(int argc, _TCHAR* argv[]){    DonaldDuck * duck = new DonaldDuck();        duck->GaGaSpeaking();             duck->OfficialWalking();             cout << "---------- hooking --------" << endl;    typedef void(*DuckFunc)();    int * addr = (int*)duck;    DuckFunc f1 = (DuckFunc)(*((int*)(*addr)));    f1();    DuckFunc f2 = (DuckFunc)(*((int*)(*addr)+1));    f2();    return 0;}

The memory layout is:

Force a call to a member function (even private)

Multiple inheritance

多继承下其实也是类似，按继承顺序依次排列，还是看代码示例

Class Iduck {public://Gaga called virtual void gagaspeaking () = 0;      Master's official step virtual void officialwalking () = 0; private:unsigned int height;}; Class Iactor {public://Funny virtual void makefun () = 0;private:std::string Name;}; Class Donaldduck:public Iduck, public iactor {public:void gagaspeaking () {std::cout <&lt ;        "DonaldDuck Speak" << Std::endl;       } void Officialwalking () {std::cout << "DonaldDuck Walk" << Std::endl;    } void Makefun () {std::cout << "Wa hahaha ~ ~ ~" << Endl;        }};int Main (int argc, _tchar* argv[]) {DonaldDuck * duck = new DonaldDuck ();             Duck->gagaspeaking ();             Duck->officialwalking ();    Duck->makefun ();    cout << "----------hooking--------" << Endl;    typedef void (*DUCKFUNC) ();    int * addr = (int*) duck; Duckfunc f1 = (duckfunc) (* (int*) (*ADDR));    F1 ();    Duckfunc F2 = (duckfunc) (* (int*) (*ADDR) +1));    F2 ();    typedef void (*ACTORFUNC) ();    int * ADDR2 = (int*) (* (int*) ((iactor*) duck));    Actorfunc F3 = (Actorfunc) (* (int*) (ADDR2));    F3 (); return 0;}

The memory layout is:

Diamond Inheritance (slight)

For more information, see

2, the interface in Go

Golang takes interface as a type and does not rely on inheritance, but rather in an implementation similar to duck-typing. The so-called duck-typing is a dynamic genre style: When an obj walks like a duck, swims like a duck, and barks like a duck, it can be called a duck.

Since go is not as demanding as C + + to tell the compiler which parent to inherit, how is the dynamic type implemented? (based on go1.6,1.7 and later version due to Nameoff inconvenient gdb printing)

First, interface consists of two parts {tab, data}, where tab holds the metadata of the interface, which is important.

type iface struct {        tab  *itab        data unsafe.Pointer}

Itab is more important in InterfaceType and fun[], where interfacetype preserves what methods the interface needs to implement, fun[] How to save the dynamic type is how to implement these methods

type itab struct {        inter  *interfacetype        _type  *_type        link   *itab        bad    int32        unused int32        fun    [1]uintptr // variable sized}type interfacetype struct {        typ  _type        mhdr []imethod}type imethod struct {        name    *string        pkgpath *string        _type   *_type}

Attached: An illustration in a classic paper

Research!rsc:go Data structures:interfaces

E.g Donald's go version

package mainimport (    "fmt")type Duck interface {    GaGaSpeaking()()    OfficialWalking()()}type Actor interface {    MakeFun()()}type DonaldDuck struct {    height uint    name   string}func (dd *DonaldDuck) GaGaSpeaking()() {    fmt.Println("DonaldDuck gaga")}func (dd *DonaldDuck) OfficialWalking()() {    fmt.Println("DonaldDuck walk")}func (dd *DonaldDuck) MakeFun()() {    fmt.Println("DonaldDuck make fun")}func main() {    dd := &DonaldDuck{10, "tang lao ya" }    var duck Duck = dd    var actor Actor = dd    duck.GaGaSpeaking()    actor.MakeFun()    dd.OfficialWalking()}

Let's debug with GDB.
First, look at the memory relationship between the structure type and the two interface

As can be seen, the data pointer of the duck and actor points to DD
Then is the set of methods for the Duck interface:

and the specific implementation of its dynamic type:

As you can see, it all points to the specific implementation of Tanglaoya

And look at the actor's method set:

and the concrete implementation of its dynamic type

3. Summary

C + + in the code to determine whether to implement an interface, and attach the interface information in their own memory, but the IS-A mode more and more limited decoupling between modules, golang its loose interface to fully reduce the occurrence of the coupling, but may be in code writing inadvertently implemented an interface. In addition, the implementation may be more around, prone to other errors (such as the classic interface and nil comparison, etc.)