For example, say I have a class Temp:
class Temp
{
public:
int function1(int foo) { return 1; }
void function2(int bar) { foobar = bar; }
To a first order approximation, the size of an object is the sum of the sizes of its constituent data members. You can be sure it will never be smaller than this.
More precisely, the compiler is entitled to insert padding space between data members to ensure that each data member meets the alignment requirements of the platform. Some platforms are very strict about alignment, while others (x86) are more forgiving, but will perform significantly better with proper alignment. So, even the compiler optimization setting can affect the object size.
Inheritance and virtual functions add an additional complication. As others have said, the member functions of your class themselves do not take up "per object" space, but the existence of virtual functions in that class's interface generally implies the existence of a virtual table, essentially a lookup table of function pointers used to dynamically resolve the proper function implementation to call at runtime. The virtual table (vtbl) is accessed generally via a pointer stored in each object.
Derived class objects also include all data members of their base classes.
Finally, access specifiers (public, private, protected) grant the compiler certain leeway with packing of data members.
The short answer is that sizeof(myObj) or sizeof(MyClass) will always tell you the proper size of an object, but its result is not always easy to predict.
sizeof(Temp)
will give you the size. Most likely, it is 4 bytes (given a whole lot of assumptions) and that is only for the int. The functions do not take up any room on a per object basis, they are compiled once, and linked by the compiler each time they are used.
It's impossible to say exactly what the object layout is, however, the standard doesn't define the binary representation for objects.
There are a few things to be aware of with binary representations, like they aren't necessarily the sum of the bytes of the data members, due to things like structure padding
If you are using Microsoft Visual C++ there is one compiler option that tells you, how large your object actually is: /d1reportSingleClassLayout
It's undocumented except for this video by Lavavej http://channel9.msdn.com/Shows/Going+Deep/C9-Lectures-Stephan-T-Lavavej-Advanced-STL-3-of-n
The size of an object of a class is equal to the sum of the sizes of all the data members of that class. For example if I have a class
class student
{
private:
char name[20];
int rollno, admno;
float marks;
public:
float tmarks, percentage;
void getdata();
void putdata();
};
Now, if I make an object of this class, say s1
, then the size of this object will be 36 bytes:
[20(name)+2(rollno)+2(admno)+4(marks)+4(tmarks)+4(percentage)]
Methods belong to the class, not any particular instantiated object.
Unless there are virtual methods, the size of an object is the sum of the size of its non-static members, plus optional padding between the members for alignment. The members will probably be laid out sequentially in memory, but the spec doesn't guarantee ordering between sections with different access specifications, nor ordering relative to the layout of superclasses.
With virtual methods present, there may be additional space taken for vtable and other RTTI information.
On most platforms, executable code goes in the read-only .text
(or similarly named) section of the executable or library, and is never copied anywhere. When class Temp
has a method public: int function1(int)
, the Temp
metadata may have a pointer to a _ZN4Temp9function1Ei
(mangled name may be different depending on compiler) function for the actual implementation, but certainly it would never contain the executable code embedded.
This may help.
Additionally, class functions are represented just like any other function. The only magic that C++ does to the function is to mangle the function names to uniquely identify a specific function with a specific set of parameters inside a specific class.