This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why class size, depends only on data members and not on member functions?
When I first learnt about Inheritance, my teacher remarked that as opposed to data members, member function don't change the class size. That is, if class B inherits from class A then B's size will be larger than A's size if and only if at least one data member will be added, and won't be changed with respect to function members quantity.
Is it correct? If so, How this mechanism works? It seems like both members should be held in the heap and therefore will cost in size.
Thank you,
Guy
Member variables are stored as part of each class instance. But member functions are not.
Each instance of a class must have a separate copy of each member variable. This keeps each object unique.
But member functions are code. And no matter how many instances you have of a particular class, there is absolutely no reason to have multiple copies of the code. The same code simply operates on the instance data.
Since code is different, code is not part of the size of a class instance. And sizeof(myClass) will not include bytes occupied by code.
You can imagine that calling a member function myClass.myMethod(x) is similar to myMethod(myClass, x). There is no need for that function to exist per every instance of class. You can access this "hidden" first argument using this keyword.
if class B inherits from class A then B's size will be larger than
A's size if and only if at least one data member will be added, and
won't be changed with respect to function members quantity.
Yes it is correct. (if B doesn't implement other methods).
Each class instance has a copy of the data members and a pointer to a member function table where they are actually stored.
The code of the member functions is shared between different instances of the same class. If B doesn't override any member function of the base class A, both A and B can share the same methods.
When you override a member function in a subclass, basically you are changing this mechanism, creating a new definition of the overriden member function, available only for the subclass where you defined it (es.B).
Normally a member function is binded at compile time. So if you have an instance of the subclass B referenced through a pointer to the base class A, and you call a member function foo() defined in both classes, the function called will be the one implemented in the base class.
You can force a member function to be binded at run-time declaring it virtual (the member function called will be the one of the actual type of the class pointed through the base pointer). This will cause an additional table (Virtual Method Table , vtable ) to be used to store virtual methods, and a double pointer indirection for each call.
Related
As far as my understanding all the member functions will be created in separate memory when class definition and is common for all objects. And only the member variables are created individually for each object. But how member function is executed when called using object?
Where is the address for these member function will be stored?
class B{
public:
int a;
void fun(){
}
};
int main(){
B b;
std::cout<<sizeof(b)<<std::endl;
}
If I execute this program, I get the output as 4(which is for only member variable). But calling b.fun() calls its member function correctly. How it is calling without storing its address within the object? Where the member function address are stored?
Is there anything like class memory layout where these addresses will be stored?
Non-virtual member functions are extremely like regular non-member functions, with the only difference between them being a pointer to the class instance passed as a very first argument upon invocation.
This is done automatically by compiler, so (in pseudo-code) your call b.fun() can be compiled into
B::Fun(&b);
Where B::Fun can be seen as a usual function. The address of this function does not have to stored in actual object (all objects of this class will use the same function), and thus size of the class does not include it.
Is there anything like class memory layout where these addresses will be stored?
There is for functions declared virtual, yes. In this case, the addresses of said functions are stored in a table and looked up at runtime. This in turn allows your code to dispatch to the correct function depending on the object's type when the function is called.
Non-virtual functions do not work this way. They're stored in the same way as free (i.e. non-member) functions, with the function name prefixed by the name of the class. No storage space within the object itself is required.
In both cases, a hidden this pointer is passed to the called function. This is what 'connects' it to your object.
I was just curious, does the creation of an object in C++ allocate space for a new copy of it's member functions? At the assembly or machine code level, where no classes exist, do all calls for a specific function from different objects of the same class actually refer to the same function pointer or are there multiple function blocks in memory and therefore different pointers for each and every member function of every object derived from the same class?
Usually languages implement functionalities as simply as possible.
Class methods are under the hood just simple functions containing object pointer as an argument, where object in fact is just data structure + functions that can operate on this data structure.
Normally compiler knows which function should operate on the object.
However if there is a case of polymorphism where function may be overriden.
Then compiler doesn't know what is the type of class, it may be Derived1 or Derived2.
Then compiler will add a VTable to this object that will contain function pointers to functions that could have been overridden.
Then for overridable methods the program will make a lookup in this table to see which function should be executed.
You can see how it can be implemented by seeing how polymorphism can be implemented in C:
How can I simulate OO-style polymorphism in C?
No, it does not. Functions are class-wide. When you allocate an object in C++ it will contain space for all its attributes plus a VTable with pointers to all its methods/functions, be it from its own class or inherited from parent classes.
When you call a method on that object, you essentially perform a look-up on that VTable and the appropriate method is called.
I think I have a clear understanding of class data members and their in-memory representation:
The members of a class define the layout of objects: data members are stored one after another in memory. When inheritance is used, the data members of the derived class are just added to those of a base.
However, when I am trying to figure out how the "blueprint" of an object is modified by its function members with additional syntax elements: I'm having difficulties. In the following text, I've tried to list all the problematic1 function member syntax that makes it difficult for me to figure out the object memory size and structure.
Class member functions that I couldn't figure out:
function type: lambda, pointer to function, modifying, non-modifying.
containing additional syntax elements: friend(with non-member), virtual, final, override, static, const, volatile, mutable.
Question:
What are the differences between the member functions with different specifiers, in the context of object memory layout and how they affect it?
Note:
I've already read this and this, which does not provide an satisfying answer2. This talks about the general case(which I understand), which is the closest to a duplicate.(BUT I am particular about the list of problematic syntax that is my actual question and is not covered there.)
1. In terms of affecting object memory layout.
2. The first is talking about the GCC compiler and the second provides a link to a book on #m#zon.
Member functions are not part of an object's memory layout. The only thing attributable to member functions is a hidden reference to an implementation-defined structure used to perform dynamic dispatch, such as a virtual method table. This reference is added to your object only if it has at least one virtual member function, so objects of classes that do not have virtual functions are free from this overhead.
Going back to your specific question, the only modifier to a member function that has any effect on the object's memory layout is virtual*. Other modifiers have an effect of how the function itself is interpreted, but they do not change the memory layout of your object.
* override keyword also indicates the presence of a virtual member function in a base class, but it is optional; adding or removing it does not change memory layout of the object.
If each member function is only contained once per class (to be shared by all instances) what exactly is the purpose of declaring a member function static? Is it like a function being declared const, in that it modifies a particular type of data (in this case, static data members)?
Normal member functions require a class instance to run. Static methods can be called directly without first creating an instance of the class.
Normal method:
MyClass myClass;
myClass.NormalMethod();
Static method:
MyClass::StaticMethod();
So normal methods are perfect for functions that work with the class data. If a method doesn't need to work with the class data, then it would be a candidate for possibly being made static.
Class methods, static or otherwise, can access private members of any of that class's objects, not just its own instance. Same goes for static methods, which don't have an instance unless you pass one to them.
You could also use a free function and declare it a friend, but a free function implies a higher level of abstraction that may operate on objects of different classes. A static class method says "I only make sense in light of my class"
One application of static methods is to create instances and return pointers. For example, there may be derived classes that the caller isn't supposed to know about - the "factory" function knows which derived class to use.
Of course when you need to create an object, you probably don't already have an object to use for that, and even if you do that other object isn't relevant.
Basically, sometimes some action is an aspect of the abstraction that a class provides, but that action isn't associated with a specific object - or at least not one that already exists. In that case, you should implement the action as a static function.
Similarly, some data is related to the abstraction provided by a class but not to a particular instance of that class. That data is probably best implemented as static member variables.
How does a C++ object know where it's member function definitions are present? I am quite confused as the Object itself does not contain the function pointers.
sizeof on the Object proves this.
So how is the object to function mapping done by the Runtime environment? where is a class's member function-pointer table maintained?
If you're calling non-virtual functions, there's no need for a function-pointer table; the compiler can resolve the function addresses at compile-time. So:
A a;
a.func();
translates to something along the lines of:
A a;
A_func(&a);
Calling a virtual function through a base-class pointer typically uses a vtable. So:
A *p_a = new B();
p_a->func();
translates to something along the lines of:
A *p_a = new B();
p_a->p_vtbl->func(p_a);
where p_vtbl is a compiler-implemented pointer to the vtable specific to the actual class of *p_a.
There are generally two ways that an object and its member functions are associated:
For a non-virtual function, the compiler determines the appropriate function at compile time. Non-static member functions are usually passed a hidden parameter that contains the this pointer, which takes care of the association of the object and the class member function.
For virtual functions, most compilers tend to use a lookup table that is usually referenced via the object's this pointer or a similar mechanism. This table, normally called the vtable, contains the function pointer for the virtual functions only.
As C++ is not a dynamic language, the compiler can do most of the object/function/symbol resolution at compile time with the exception of some virtual functions. In some cases, it's even possible for the compiler to determine exactly which instance of a virtual function gets called and skip the resolution via the vtable.
Member functions are not part of the object - they are defined statically, in one place, just like any other function. There is no magic look-up needed.
Virtual functions are different, but I don't think your question is about that...
For non-virtual functions there is one (global, per-class) function table which all instances use. Since it's the same for all of them - deterministic at compile-time - you would not want it duplicated in each instance.
For virtual functions, resolution is done at runtime and the object will contain a function table for them. Try that and look at your object again.