If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Memory Address of Class Member Variables

Hello,

Suppose I have two classes, MyClassX and MyClassY, each with two member variables, as defined below. I create an object instance of each class, and then create a pointer to each member variable for each object:

After converting the hexadecimal to decimal, it appears that with MyClassX, pxb is 8 bytes from pxa, whereas for MyClassY, pya is only 4 bytes from pyb. This makes sense for MyClassY, because the first member variable to be stored is an int, and so will occupy 4 bytes. However, why should this be any different for MyClassX, which also has an int as the first member variable, so shouldn't this also occupy 4bytes?

The reason I have come across this problem is that I am looking into streaming objects to memory and then loading them again. (I know boost can do this, but I am trying it out myself from scratch.) Therefore, this is causing an issue, because I cannot just assume that the size of memory occupied by an object is just the sum of the sizes of its member variables. MyClassX is 8 bytes larger than MyClassY, even though the intuition is that it should only occupy 4 bytes more due to a double being replaced by an int.

Re: Memory Address of Class Member Variables

Yes. sizeof(classname) or sizeof(classinstance) will give the same result as sizeof(..) is evaluated at compile time. The compiler determines the layout and hence the size of the class at compile time and this doesn't change during program execution.

All advice is offered in good faith only. You are ultimately responsible for effects of your programs and the integrity of the machines they run on.

Re: Memory Address of Class Member Variables

Originally Posted by 2kaud

Corrrect! c++ can also store additional info in the class such as virtual pointers etc.

There will typically only be a single vtable pointer in a class regardless of how many virtual functions there are, so you can expect a class to grow by the size of a single pointer if it has virtual functions
However this isn't guaranteed, it is possible that this doesn't affect the sizeof().
virtual multiple inheritance may or may not affect this further, and other meta data in the class (runtime type information) can have an effect on the sizeof as well.

However, why should this be any different for MyClassX, which also has an int as the first member variable, so shouldn't this also occupy 4bytes?

you're getting padding bytes after the int in the 1st class to make sure the double is aligned on an 8byte boundary.

you will want to set an explicit packing (this is compiler dependant, VS does it with #pragma pack) to make sure no header has changed this to something unexpected and forgot to restore it.

The reason I have come across this problem is that I am looking into streaming objects to memory and then loading them again.

if you want to stream a class... provide a virtual load/save (or saveload(bool bSave)) or << and >> operators or whatever explicitely and stream individual members there.
Do not assume that in any shape or form you can get a reliable and generic save/load for all cases by saving(loading) sizeof() bytes starting at the address of the class instance.

it can work for pure data classes if you don't use inheritance. Anything else may not be portable across platforms, or even across versions of the same compiler brand.

besides, if you store something like a std::string or MFC CString, then the string pointed to won't even be part of the sizeof of your class, so you need "special" code for this case anyway. The same holds for any pointers or references or containers in your class.

* The Perfect Platform for Game Developers: Android
Developing rich, high performance Android games from the ground up is a daunting task. Intel has provided Android developers with a number of tools that can be leveraged by Android game developers.

* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.