As I understand, each instance of a class has its own member variables in memory, so that it can store different values for different objects. However, it is not the same for member functions. Member functions are reused across objects of a class, so it only has one address with one block of memory to refer when needed by all objects.
Static function is made to access static members. However, static function also exists only once during the lifetime of its application. Aside from being the accessor to static members, at low level it is not different with normal class functions, isn't it? Or maybe I'm wrong, that each class has its memory space for functions?
Difference between static method and non static function in memory
You didn't mention the technology you are using. Most language implementations treat static and member functions as practically the same thing - a block of code with a set of parameters. For a member function, the first parameter is some kind of reference to the object itself.
You can almost think of member functions as static functions with an implicit "this" parameter:
(This ignores dynamic binding).
You can almost think of member functions as static functions with an implicit "this" parameter:
class Example
{
private int a
private int b
public function foo()
{
return a * b
}
}
// Almost like
class Example
{
private int a
private int b
public static function foo(Example this)
{
return this.a * this.b
}
}
(This ignores dynamic binding).
Static function is made to access static members.
[/quote]
There are other reasons to make a function static. Sometimes one does it to call private functionality (e.g. a static factory function which can call private constructors). Other times it is because a function doesn't have a logical object it works on. A function like object.collides(other) could be written as Object::collision(object, other).
Or maybe I'm wrong, that each class has its memory space for functions?
[/quote]
I'm not sure what distinction you are making here. At some level, each function is going to be somewhere in memory.
Some implementations will be clever. For example, on MSVC++, if you have two different functions, in different classes, that happen to compile to the same assembly, in Release builds the linker will only emit that assembly once, and use it for both functions. This happens quite often in small functions, like simple accessor/mutator functions.
Author
You didn't mention the technology you are using. Most language implementations treat static and member functions as practically the same thing - a block of code with a set of parameters. For a member function, the first parameter is some kind of reference to the object itself.
Sorry about that. I am concerning with C/C++ implementation. But I think it should be the same principle for every language.
I'm not sure what distinction you are making here. At some level, each function is going to be somewhere in memory.
Some implementations will be clever. For example, on MSVC++, if you have two different functions, in different classes, that happen to compile to the same assembly, in Release builds the linker will only emit that assembly once, and use it for both functions. This happens quite often in small functions, like simple accessor/mutator functions.
[/quote]
I know that functions must be stored in memory. However, I'm not sure if each class object will have its own function or (and should be) all class objects will refer to the same function stored in memory. The only unique thing each class object should have is its data members.
At some low level, an object is a data structure, and functions are not part of it (virtual functions make this statement less true, but let's ignore that for a minute). Non-static member functions are just functions that take a first parameter which is a pointer to the object on which they are called, whose name is `this' (a `const' method is one where the `this' pointer is a `const' pointer). Static member functions are the same thing as regular functions. The language allows member functions access to private and protected data, but this is in some sense a higher layer.
The description of objects as being something that contains both the data and the code that operates on the data is misleading and you should try to forget it. As a tool to organize your program, a class does provide a single entity that describes the data and how you operate with it, but individual objects only contain the data.
Virtual functions are a bit different, in that the object itself will have some mechanism to retrieve the appropriate version of the function to be called in a dynamic dispatch. The most common mechanism to do this is a so-called vtable.
While we are at it, you can think of a class that inherits from another class as having a data member of that class. If the inheritance is public, protected or private, think of it as that data member being public, protected or private. If the inheritance is virtual, the member is actually a pointer to the parent class. But I have never ever needed virtual inheritance for anything. If you find yourself needing it, you probably went too far with your inheritance hierarchy.
This is basically how I think of objects in C++. There are some layers of syntactic sugar on top of that (for instance, the way you invoke a member function hides the passing of the `this' pointer). I hope this makes things a bit more clear.
The description of objects as being something that contains both the data and the code that operates on the data is misleading and you should try to forget it. As a tool to organize your program, a class does provide a single entity that describes the data and how you operate with it, but individual objects only contain the data.
Virtual functions are a bit different, in that the object itself will have some mechanism to retrieve the appropriate version of the function to be called in a dynamic dispatch. The most common mechanism to do this is a so-called vtable.
While we are at it, you can think of a class that inherits from another class as having a data member of that class. If the inheritance is public, protected or private, think of it as that data member being public, protected or private. If the inheritance is virtual, the member is actually a pointer to the parent class. But I have never ever needed virtual inheritance for anything. If you find yourself needing it, you probably went too far with your inheritance hierarchy.
This is basically how I think of objects in C++. There are some layers of syntactic sugar on top of that (for instance, the way you invoke a member function hides the passing of the `this' pointer). I hope this makes things a bit more clear.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement