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.

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)

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).

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.