Memory usage of member functions

[rwan]

Hi all,

I am writing a program which will have many instances of a class (in, say, an array) and am concerned about memory usage. Suppose I have this kind of class:

class foo {
public:
fn ()
private:
unsigned int var;
}

and let's say I have a lot of instances of this -- n of them in an array. In memory, will there be n copies of fn () or just one? Of course, if it is just 1, then that's great. If there will be n copies, then I am contemplating making fn () a non-member function that operates on foo instead. (My concern is that I'll have a lot of fn ()'s, so I can write just one accessor to var instead.)

I vaguely remember learning about this eons ago and think it is just one copy in some central place that all instances of foo can access...but I can't remember what this is called or how to search for it in a search engine.

Thank you!

Ray

[1yR4jE8b]

The way I understand functions and their place in memory (I'm no expert, so I expect someone to correct me), is that every member function has a hidden parameter 'this' which is a pointer to the calling object.

When you address a member of that class in a function, 'this->member' is used implicitly if you don't specify the 'this' pointer yourself.

This would seem to indicate to me, that because there is an implicit pointer to the caller, that there is only one copy of the function in memory.

[Duthomhas]

Your analysis is correct: there is only one copy of the function in memory.

Be careful with virtual functions though... using them adds additional memory to your class because individual copies of your class must then keep track of which function is correct to call.

So, stick to classes that don't use the keyword "virtual" and don't inherit from classes that do.

[rwan]

Ah, great! Thank you both for your replies and explanation! I'll be sure to stay away from virtual functions as well.

I was on the verge of pulling my class definition apart to "save" memory. I'm glad I asked as that would have been the wrong thing to do...

[rapidcoder]

Of course, all the method members take space in a per-class manner, not per-object - the code of a single method of a single class is kept in memory only once, regardless of the number of objects.

Be careful with virtual functions though... using them adds additional memory to your class because individual copies of your class must then keep track of which function is correct to call.

A bit unclear explanation. What are "individual copies of the class"? You meant instances? If instances, then you are wrong.

The first virtual method adds usually a single pointer to the object, the next virtual methods are for free. So you should be careful, when you keep extremely large amounts of really small objects (like 4-16 bytes). Then, the 4 or 8 bytes overhead might be a problem. But for large objects, that single pointer won't make a noticeable difference.

What virtual adds to your class definitions is a virtual method table - there is only one per class, and it contains pointers to all the virtual methods in that class. Usually a few pointers in the vmt take relatively little space compared to the actual code defined in the class. So, again, in most cases, you won't probably even notice.


The more serious downside of virtual calls in C++ is that in most cases they can't be inlined.
So calling them may incur some significant time overhead, compared to statically resolved, inlined calls. Therefore, you have to think if you really want the runtime polymorphism, or maybe the (weaker) compile time polymorphism (templates) suffice.

[rwan]

Thank you for further explaining about virtual methods. I actually don't use them (mainly because I have not had the need to read up on them...yet). Even so, it is good to know.

The first virtual method adds usually a single pointer to the object, the next virtual methods are for free. So you should be careful, when you keep extremely large amounts of really small objects (like 4-16 bytes). Then, the 4 or 8 bytes overhead might be a problem. But for large objects, that single pointer won't make a noticeable difference.

That is actually my situation (many small objects), but I didn't mention it as I didn't think it was important.

I'm not yet at a point where I need runtime polymorphism, but if/when I do, I'll probably need to brush up on virtual methods since there seems to be a lot of things to look out for.

Thank you for the explanation!