How is inheritance implemented at the memory level?

前端 未结 5 1118
无人共我
无人共我 2021-02-13 15:36

Suppose I have

class A           { public: void print(){cout<<\"A\"; }};
class B: public A { public: void print(){cout<<\"B\"; }};
class C: public A         


        
相关标签:
5条回答
  • 2021-02-13 16:04

    I don't think the standard makes any guarantees. Compilers can choose to make multiple copies of functions, combine copies that happen to access the same memory offsets on totally different types, etc. Inlining is just one of the more obvious cases of this.

    But most compilers will not generate a copy of the code for A::print to use when called through a C instance. There may be a pointer to A in the compiler's internal symbol table for C, but at runtime you're most likely going to see that:

    A a; C c; a.print(); c.print();
    

    has turned into something much along the lines of:

    A a;
    C c;
    ECX = &a; /* set up 'this' pointer */
    call A::print; 
    ECX = up_cast<A*>(&c); /* set up 'this' pointer */
    call A::print;
    

    with both call instructions jumping to the exact same address in code memory.

    Of course, since you've asked the compiler to inline A::print, the code will most likely be copied to every call site (but since it replaces the call A::print, it's not actually adding much to the program size).

    0 讨论(0)
  • 2021-02-13 16:09

    In your example here, there's no copying of anything. Generally an object doesn't know what class it's in at runtime -- what happens is, when the program is compiled, the compiler says "hey, this variable is of type C, let's see if there's a C::print(). No, ok, how about A::print()? Yes? Ok, call that!"

    Virtual methods work differently, in that pointers to the right functions are stored in a "vtable"* referenced in the object. That still doesn't matter if you're working directly with a C, cause it still follows the steps above. But for pointers, it might say like "Oh, C::print()? The address is the first entry in the vtable." and the compiler inserts instructions to grab that address at runtime and call to it.

    * Technically, this is not required to be true. I'm pretty sure you won't find any mention in the standard of "vtables"; it's by definition implementation-specific. It just happens to be the method the first C++ compilers used, and happens to work better all-around than other methods, so it's the one nearly every C++ compiler in existence uses.

    0 讨论(0)
  • 2021-02-13 16:22

    Compilers are allowed to implement this however they choose. But they generally follow CFront's old implementation.

    For classes/objects without inheritance

    Consider:

    #include <iostream>
    
    class A {
        void foo()
        {
            std::cout << "foo\n";
        }
    
        static int bar()
        {
            return 42;
        }
    };
    
    A a;
    a.foo();
    A::bar();
    

    The compiler changes those last three lines into something similar to:

    struct A a = <compiler-generated constructor>;
    A_foo(a); // the "a" parameter is the "this" pointer, there are not objects as far as
              // assembly code is concerned, instead member functions (i.e., methods) are
              // simply functions that take a hidden this pointer
    
    A_bar();  // since bar() is static, there is no need to pass the this pointer
    

    Once upon a time I would have guessed that this was handled with pointers-to-functions in each A object created. However, that approach would mean that every A object would contain identical information (pointer to the same function) which would waste a lot of space. It's easy enough for the compiler to take care of these details.

    For classes/objects with non-virtual inheritance

    Of course, that wasn't really what you asked. But we can extend this to inheritance, and it's what you'd expect:

    class B : public A {
        void blarg()
        {
            // who knows, something goes here
        }
    
        int bar()
        {
            return 5;
        }
    };
    
    B b;
    b.blarg();
    b.foo();
    b.bar();
    

    The compiler turns the last four lines into something like:

    struct B b = <compiler-generated constructor>
    B_blarg(b);
    A_foo(b.A_portion_of_object);
    B_bar(b);
    

    Notes on virtual methods

    Things get a little trickier when you talk about virtual methods. In that case, each class gets a class-specific array of pointers-to-functions, one such pointer for each virtual function. This array is called the vtable ("virtual table"), and each object created has a pointer to the relevant vtable. Calls to virtual functions are resolved by looking up the correct function to call in the vtable.

    0 讨论(0)
  • 2021-02-13 16:23

    Check out the C++ ABI for any questions regarding the in-memory layout of things. It's labelled "Itanium C++ ABI", but it's become the standard ABI for C++ implemented by most compilers.

    0 讨论(0)
  • 2021-02-13 16:23

    There will not be any information stored in a object to describe a member function.

    aobject.print();
    bobject.print();
    cobject.print();
    

    The compiler will just convert the above statements to direct call to function print, essentially nothing is stored in a object.

    pseudo assembly instruction will be like below

    00B5A2C3   call        print(006de180)
    

    Since print is member function you would have an additional parameter; this pointer. That will be passes as just every other argument to the function.

    0 讨论(0)
提交回复
热议问题