What does an object look like in memory? [duplicate]

Answer 1

You've asked a few questions here...

Layout

All the non-static members are organised in memory much like a struct. There may be padding if the compiler chooses to put any in. If you have an array of objects, it's just like an array of structs

Static members

Are stored separately, obviously. One copy.

Function calls

There's a little magic going on behind the scenes for classes. When you call a member function it is much like any other function except it has a different calling convention. Effectively, this inserts the object's pointer (this) into the parameter list.

[edit: the code for the function itself is not stored with your object -- this allows you to do fun things like delete this and continuing execution of a member function provided you no longer access the object you just deleted].

When you have overloaded or polymorphic functions, things get a little more magical. This article is an explanation that I googled up in about 5 seconds. I'm sure there are many more. I've never much concerned myself with the internals of object calls, but it's always nice to know.

You should try the exercise of making a class exhibiting all these different aspects and look at the assembly generated in each case. I have done that before when tuning some time-critical code.

Answer 2

Static class members are treated almost exactly like global variables / functions. Because they are not tied to an instance, there is nothing to discuss regarding memory layout.

Class member variables are duplicated for each instance as you can imagine, as each instance can have its own unique values for every member variable.

Class member functions only exist once in a code segment in memory. At a low level, they are just like normal global functions but they receive a pointer to this. With Visual Studio on x86, it's via ecx register using thiscall calling convention.

When talking about virtual functions, polymorphism, then the memory layout gets more complicated, introducing a "vtable" which is basically a bunch of function pointers that define the topography of the class instance.

Answer 3

As you suspect, the data members (fields) are laid out sequentially. This also includes the fields of base classes.

If the class (or one of its base classes) contain any virtual methods, the layout typically starts with vptr, i.e a pointer to a virtual table (or vtable) which is a table of pointers to function implementations related to that class. Please note that this is not defined by standard, but AFAIK all current compilers use this approach. Also, with multiple inheritance it gets more hairy, so let's ignore it for the moment.

+-----------+
|  vptr     |  pointer to vtable which is located elsewhere
+-----------+
|  fieldA   |  first member
|  fieldB   |  ...
|  fieldC   |
|  ...      |
+-----------+

Fields can take more space then the sum of their individual sizes, which depends on packing (e.g. 1 byte packing ensures there are no gaps, but is less efficient than the 4 or 8 byte packing with regard to performance).

Member functions (non static) receive the pointer to the object, usually via ecx register on x86 architecture. This is also not defined by the standard.

Static functions are similar to global functions, and they operate on static class fields (shared for all instances of a class) which are located in the data segment.

Answer 4

First thing to note is that in C++ the term "object" includes things like integers.

Next thing is, structures are laid out pretty much how you'd expect. One member following the next in memory with an undefined amount of padding between.

When a class inherits from another then the class will start with its base class, which in turn may start with a base class of its own. Thus Derived* and Base* will be the same value in cases of single inheritance. Following the base's area (its members) will be the derived class's members in turn, with an undefined amount of padding between them.

When a class inherits from more than one base then things become a little different. The base areas are laid out in memory sequentially. Base1 followed by Base2, etc...after which the derived class's members are laid out in turn with an undefined amount of padding between them.

If the object is of a POD class then it is guaranteed that the first member in the class will be at the location in memory the object resides. This means that Class* and Class->firstMember* will be the same value. I don't believe this applies to non-POD entities.

In the case of polymorphic classes, those with virtual functions, an additional secret member will be created called the vtable. This isn't guaranteed by anything in the standard, but is pretty much the only way to do it and follow the rules that are. Each class has this, so if your class has bases then it will have its table and you'll have yours for additional functions.

All member functions will have their names mangled and parameters modified to accept this as the first argument. This happens behind the scenes as the compiler builds stuff. Virtual functions will be pointed at by the vtable. Non-virtuals will simply be resolved statically and used directly.

Static members are not members of the object created by a class. A static member is simply a global variable with different scope.

Answer 5

It will have its member variables laid out, and also a virtual function table if it is polymorphic which will include a list of pointers to the functions that its virtual methods are actually associated with.

Static means just one copy.