You are here:

C++/Memory layout for class instance.


Hi Dear Ralph!
Thanks for being a C++ Expert.
My questions are:
When I create a new class instance, how much memory is allocated for it?
How an instance calls it's methods?

I had more questions but trying to write them here in a correct way, I found answers to them. :)

Thanks in advance!
Waiting for feedback.
Have a great week!

When I create a new class instance, how much memory is allocated for it?
The size of a class instance depends on the class definition - specifically what instance data members it defines and whether it uses any virtual member functions. The size of any object can be obtained from the sizeof operator which is evaluated at compile time:

   sizeof <expression>

Where <expression> is some expression that yields a result which has a type which has a size and <type> describes a type.

So simple examples might be:

   MyClass myobj;
   assert( sizeof(MyClass)==sizeof myobj );

The value returned by sizeof is an unsigned integer of type std::size_t.
The returned value is in units of bytes.
Previously this was defined to be in units of char - that was sizeof(char)==1 by definition.

[Note: The C++11 standard (N3337) defines a byte as:
   "A byte is at least large enough to contain any member of the basic execution
    character set (2.3) and the eight-bit code units of the Unicode UTF-8 encoding
    form and is composed of a contiguous sequence of bits, the number of which is
    implementation defined."

and a char as:

   "Objects declared as characters (char) shall be large enough to store any member
    of the implementationís basic character set. ..."

Which you will note are:
   a) similar but not the same and not defined one in terms of the other.
   b) do not explicitly mention any specific bit-width.

In practice it is common for both byte and char to be 8-bits wide.
-- end note]

The size of a class object instance is _at_ _least_ the size of each of it instance data member added together but in practice may well be more as the compiler will typically add padding to align larger members to an appropriate boundary in memory. Also if the class has virtual member functions then extra space is required to support this feature - see vtable, for example in a Google, Bing etc. search. More such housekeeping may be required if the class has multiple bases.

For example a class with a couple of char members like so:

   class BiChar
       char a_;
       char b_;



might have a size of 2, 4 or 8 (assuming each char is 1 byte in size) depending on whether class instances are themselves aligned on 1 or 2, 4 or 8 byte boundaries (i.e. its address in memory will be divisible by 1 or 2, 4 or 8), and if they generally are, say, aligned to 8 byte boundaries whether the compiler makes an exception for small instances like BiChar has. If no such exception is in place then the size of 2 bytes required for the a_ and b_ members may need to be padded out to a size of 4 or 8 depending on the object instance alignment requirements.

Whereas a class like so:

   class CharIntChar
       char a_;
       int i_;
       char b_;



[Note: here and below the ... is meant to mean potentially other code I am not showing rather than the C/C++ ellipsis used to indicate a variable number of arguments --end note]

might have a size of 6, 9, 12 or 16 or some other size, again depending on alignment. Assuming each int has size 4 and should be aligned on a 4-byte boundary and that objects are similarly aligned as a whole on 4 or 8 byte boundaries then after the a_ member there needs to be 3 bytes of padding to align to the next 4 byte boundary required by the i_ member but the b_ member will not generally need padding before it.

Running though the thought processes: we have a raw size of 1 + 4 + 1 bytes (=6 bytes) for the sizes of the individual members. However this would leave i_ not starting on a 4-byte boundary so we will typically have a size of 1 + 3 + 4 + 1 bytes (=9 bytes), where the 3 bytes is internal padding added by the compiler. This 9 bytes may then itself need to be padded up to the next 4 or 8 byte boundary (requiring 3 or 7 bytes of padding respectively) yielding an object size of 12 or 16 bytes respectively.

Note that the reason to care about alignment is that processors often perform better for 'properly' aligned data or enforce such alignments by generating a hardware fault, trap or exception for mis-aligned data.

So the size of an object as returned by sizeof indicates the minimum size allocated for an object - the compiler or runtime free-store management (for new and delete) might allocate more in some cases - one specific example is that in debug builds a debug free-store implementation might allocate additional guard bytes before and after the memory allocated for an object to try to catch memory write under and over runs.

How an instance calls it's methods?

I am sorry but I am not sure what you mean here so sorry if I am not answering what you wanted to know.

You write the calls to the instance member functions in the code:


They do not have to be within an instance member function but one such function can call another.
For example:


which is shorthand for:


If you look carefully at each call you will notice the object in whose context the instance member function is called is named on the left of the . or ->, even within other instance member functions once the shorthand version is expanded to include the this-> prefix.

One question you should ask is:

   Where does the value for this come from inside instance member functions?

Well how about, just for the purposes of exposition, we reformulate an instance member function call like so:

   MyClass::instance_function(&myobj, ...);
   MyClass::instance_function(my_obj_ptr, ...);

And re-declare MyClass::instance_function like so:

   MyClass::instance_function(MyClass * this, ...);

Or if MyClass::instance_function were const:

   MyClass::instance_function(...) const;

we could reformulate like so:

   MyClass::instance_function(MyClass const * this, ...);

You will notice two things:

   First, the calls now pass the associated object instance as a pointer to the object as the first argument,
   which is for the parameter called this.

   Second, I have qualified the function with the name of the class. As we are reformulating the call as
   a straight function call the compiler would have to know where to look for the instance_function function.

Of course the compiler effectively does all this for us behind the scenes. It also knows the type of the object we are making an instance member function call on when using the:


forms and so knows the class specification in which to search for an instance member function.

Note again that the reformulations were only for exposition. We cannot flip between the two forms quite so easily. However if you declared the reformulated MyClass::instance_function static and changed the this parameter's name to something like self (as this is a reserved keyword in C++) it would probably work.

Hope this helps a bit.


All Answers

Answers by Expert:

Ask Experts


Ralph McArdell


I am a software developer with more than 15 years C++ experience and over 25 years experience developing a wide variety of applications for Windows NT/2000/XP, UNIX, Linux and other platforms. I can help with basic to advanced C++, C (although I do not write just-C much if at all these days so maybe ask in the C section about purely C matters), software development and many platform specific and system development problems.


My career started in the mid 1980s working as a batch process operator for the now defunct Inner London Education Authority, working on Prime mini computers. I then moved into the role of Programmer / Analyst, also on the Primes, then into technical support and finally into the micro computing section, using a variety of 16 and 8 bit machines. Following the demise of the ILEA I worked for a small company, now gone, called Hodos. I worked on a part task train simulator using C and the Intel DVI (Digital Video Interactive) - the hardware based predecessor to Indeo. Other projects included a CGI based train simulator (different goals to the first), and various other projects in C and Visual Basic (er, version 1 that is). When Hodos went into receivership I went freelance and finally managed to start working in C++. I initially had contracts working on train simulators (surprise) and multimedia - I worked on many of the Dorling Kindersley CD-ROM titles and wrote the screensaver games for the Wallace and Gromit Cracking Animator CD. My more recent contracts have been more traditionally IT based, working predominately in C++ on MS Windows NT, 2000. XP, Linux and UN*X. These projects have had wide ranging additional skill sets including system analysis and design, databases and SQL in various guises, C#, client server and remoting, cross porting applications between platforms and various client development processes. I have an interest in the development of the C++ core language and libraries and try to keep up with at least some of the papers on the ISO C++ Standard Committee site at


©2016 All rights reserved.