Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Baling

Does member functions reside in memory during runtime?

This topic is 6531 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi guys and gals, I''ve got this question here, after seeing some people actually use an object (class) for each tile on their map: will it take up a lot of memory space? Are member functions of a class resides in memory only when they''re called? Then what does the memory reserved for an object hold? Only class members? Something else? Thanks a lot for your time and perhaps, your answers.

Share this post


Link to post
Share on other sites
Advertisement
Well, I don''t use an instance of an object each and every. Instead, I use 1 instance for a type of tile. I set the pointer to that object. Since every object is told where to draw and since tiles are pretty stupid objects (meaning that they don''t do much other than draw), then this works out pretty good.

Dino M. Gambone

Good judgement is gained through experience. Experience, however, is gained through bad judgement.

Share this post


Link to post
Share on other sites
>will it take up a lot of memory space?

Only as much data as is stored in the class members.

>Then what does the memory reserved for an object hold? Only >class members?

I'm assuming just class member data. There would also be info that tells what type of object it is. But that goes beyond my
knowledge.


The function members of a class act on all objects created by
it. An object just contains data that its class member
functions can act on.





Edited by - Davaris on August 31, 2000 10:06:47 PM

Share this post


Link to post
Share on other sites
To answer your question, yes the member functions reside in memory. Once. However, each object instance references the same (single) code location to access the member function code. And yes, there is additional overhead with using a C++ object, and it doesn''t use ''just'' the memory necessary for the member data. It also has what is called a v-table, or a table of function pointers to the member functions. Without this extra ''vtable'' information, we could not have polymorphism, fundamental to OOP. Remember, with C++, each function call to an object member function (any object) incurs an additional pointer (the vtable) dereference over and above the overhead typical in C function calls. This is one of the reasons C is faster than C++.

To test this for yourself, look at the address of a member function in your debugger. Now, iterate through an array or list of similar type objects, and note that the address for the function is the same. In VC++ what you actually see is the vtable address and the function name as an offset, but the fact that you find a single copy of the code should suffice...
The overhead isn''t that bad really, unless your tile class is huge. Dino''s idea is what you would typically find out there. Use a single instance if you can; it''s good practice and it''s gentle on the system.
(I''m not advocating C over C++ in any way by some of the above statements, just stating related facts... I use both religiously. If I really needed performance over maintainability, I would use assembler. _Optimized_ C++ code is sufficiently fast for all but the most critical real-time applications. - end soapbox)

Share this post


Link to post
Share on other sites
fingh''s description pretty much explained the memory space issue. Regarding performance, one thing to note is that the vtable overhead concerns virtual member functions.

Any decent compiler will calculate the actual addresses for non-virtual member functions during compile-time, removing the need for runtime vtable calculation for these calls.

Compared to ordinary functions, all member functions (with the exception of static members) do incur overhead in the form of the implicitly passed "this" pointer. Of course, an equivalent C function would need access to the data through arguments (like a pointer to a struct), which would involve essentially the same amount of operations.

Share this post


Link to post
Share on other sites
Ok, lets get this out of the way RIGHT NOW:

Using Classes in C++ does not cost ONE byte of memory, or ONE function call more than programming in C.

That statement is TRUE - but there are dozens of other features in the C++ language that make it USEFUL and that DO cost a little for their use.

IF you turn on RTTI (run time type identification) than you are paying a cost of either one integer or one pointer per instance of a class that uses them (this makes it not very expensive for large classes, but VERY costly for lightweight classes for which you might instantiate thousands of instance) - there MAY be optimizations for RTTI that reduce this cost, but I do not know of them.

IF you use virtual functions - then every instance of the class must have a VTABLE - once again at the cost of one pointer per object (the pointer TO the vtable) - the vtable itself is shared by all objects of the class, so it''s memory is negligable. Using multiple virtual functions incurs NO MORE overhead, but using MULTIPLE INHEIRITANCE with classes which use vtables, increases the cost to one vtable per base class (unless the inheiritance is also virtual - then shared vtable are consolodated). Virtual tables ALSO cost one level of pointer indirection in the call, but once again this cost is incurred only for VIRTUAL function, which should be used only when they provide a behavior not availible without them (polymorphism).

The fact that members function pass an implicit ''this'' pointer is true, therefore if MISSUED they cost one pointer''s worth of stack space over C, BUT YOU MUST realize that members function are to be used ONLY when the this pointer would have been passed as a parameter in the C equivilent function. IF YOU DO NOT NEED THE THIS POINTER, than you are not talking about a member function, EITHER MAKE IT A GLOBAL FUNCTION in a namespace (or not) or make it a STATIC member function. This is not a language cost issue, but an incorrect coding issue. Member functions mean function which use the classes data members, otherwise they are class function (the old name from smalltalk which are implemented as ''static'' functions in C++).

Hope this proves both informative, and helpfull (because armed with this information you can make C++ programs as efficient as possible, avoiding costs when unneeded, accepting them when worthwhile).

Share this post


Link to post
Share on other sites
My previous post assumes the use of polymorphism and solid OOP techniques that are likely to be used in any large-scale project. Spock is correct, and as I should have stated, the vtable only exists for objects in which there exists one or more virtual functions(including those existing in any base classes). While it is possible to program in C++ without ever using virtual functions (as Xai implies), you may consider whether or not you actually need to use an object oriented approach for that particular task, and you should also question whether the code will be reusable. If you ever use a class library that requires you to derive from existing base classes you might want to understand the associated overhead. (Anyone heard of MFC?) There IS additional overhead in using C++ (when used practically), even if it is only dereferencing the occasional vtable and the ''this'' pointer. To say otherwise is incorrect. If you can write code that performs complex tasks, adheres to good programming practice and doesn''t access a vtable or ''this'' pointer, then I would expect to find it in some obfuscated code contest online, but not in a commercial application. My original post was in response to the original question and to some of the other answers previously provided.
So to recap: Yes object member functions reside in memory. Yes, you might incur some additional overhead in using a class. Is it as negligible as Xai claims? Most likely unless you are doing some REALLY wierd stuff in the class. And, as previously stated, but seemingly misunderstood, I do not favor C over C++, but was merely pointing out some related issues. I understand the language cost issues, as I do performance-critical embedded programming for a living. Does the overhead of C++ make it a less viable option for development? Of course not - it''s maintainable.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!