views:

165

answers:

6

Suppose I have

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

How is inheritance implemented at the memory level?

Does C copy print() code to itself or does it have a pointer to the it that points somewhere in A part of the code?

How does the same thing happen when we override the previous definition, for example in B (at the memory level)?

+1  A: 

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.

yesraaj
@yesraaj: I was referring to the class code. Does `C class` copy `print()` definition to itself or just uses a pointer to `print()` in `A class`?
Amoeba
@cambr I don't think class will be stored as it is any where. Any way lets wait for few more answers
yesraaj
+1  A: 

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.

DevSolar
+1  A: 

In C++, classes with virtual methods will have a "v-table" attached to objects of that class. When an object is constructed, the v-table is filled in with pointers to the functions implementing the methods.

class A {
public:
    virtual v1( void ){ cout << "A::v1"; };
    virtual v2( void ){ cout << "A::v2"; };
};

class B : public A {
public:
    virtual v1( void ){ cout << "B::v1"; };
};

class C : public A {
public:
    virtual v2( void ){ cout << "C::v2"; };
};

Class A will have a v-table with two elements in it. If you create an instance of Class A, v-table[0] will be set to A::v1 and v-table[1] will be set to A::v2. An instance of Class B will set v-table[0] to B::v1 while v-table[1] will be set to A::v2. Similarly, an instance of Class C will set v-table[0] to A::v1 with v-table[1] set to C::v2.

All this is very compiler dependent, but this is the general idea.

David Smith
Non-virtual methods are most definitely inherited. But the compiler can always call the correct method directly.
Ben Voigt
...for an appropriate definition of "correct". ;-)
DevSolar
I Removed my statement about nothing being inherited without the virtual keyword.
David Smith
+1  A: 

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.

cHao
+3  A: 

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).

Ben Voigt
+1 In the original example, `B` and `C` are unrelated, but interpreting it as `A` and `C` the argument holds.
David Rodríguez - dribeas
yeah... I only checked that the inheritance was public and not virtual, and not which class was inherited. oops. fixed.
Ben Voigt
+3  A: 

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);
B_bar(b);

Notes on virtual methods

Things get a little trickier when you talk about virtual methods. In that case, each object created gets an extra hidden table, called the vtable, which is an array of pointers-to-functions, one such pointer for each virtual function. Calls to virtual functions are resolved by looking up the correct function to call in the vtable.

Max Lybbert
+1 for bringing name mangling and the compiling process into discussion. Besides getting more complex (not necessarily through a vtable) with virtual methods, it gets even messier with multiple and virtual inheritance... probably out of the scope of the question.
David Rodríguez - dribeas
Yeah, I didn't want to get into the details of multiple inheritance or virtual inheritance.
Max Lybbert