How are objects stored in memory in C++?

Question

How are objects stored in memory in C++?

For a regular class such as

class Object
    {
public:
    int i1;
    int i2;
    char i3;
    int i4;
private:
    };

Using a pointer of Object as an array can be used to access i1 as follows?

((Object*)&myObject)[0] === i1?

Other questions on SO seem to suggest that casting a struct to a pointer will point to the first member for POD-types. How is this different for classes with constructors if at all? Also in what way is it different for non-POD types?

Edit:

In memory therefore would the above class be laid out like the following?

[i1 - 4bytes][i2 - 4bytes][i3 - 1byte][padding - 3bytes][i4 - 4bytes]

Answer 1

Classes without virtual members and without inheritance are layed out in memory just like structs. But, when you start getting levels of inheritance things can get tricky and it can be hard to figure out what order things are in memory (particularly multiple inheritance).

When you have virtual members, they have a "vtable" in memory which contains pointers to the actual function which gets created based on the inheritance hierarchy of the class.

The bottom line is: don't access classes this way at all if you can avoid it (and also don't memset them or memcpy them). If you must do this (why?) then take care that you know exactly how your class objects are going to be in memory and be careful to avoid inheritance.

Answer 2

It's difference in that this trick is only valid for POD types. That's really all there is to it. The standard specifies that this cast is valid for a POD type, but makes no guarantees about what happens with non-POD types.

Answer 3

Usually what matters isn't whether the class has a constructor: what matters is whether the class has any virtual methods. For details, google for 'vtable' and 'vptr'.

Answer 4

Almost. You cast to an Object*, and neglected to take an address. Let's re-ask as the following:

((int*)&myObject)[0] == i1

You have to be really careful with assumptions like this. As you've defined the structure, this should be true in any compiler you're likely to come across. But all sorts of other properties of the object (which you may have omitted from your example) will, as others said, make it non-POD and could (possibly in a compiler-dependent way) make the above statement not true.

Note that I wouldn't be so quick to tell you it would work if you had asked about i3 -- in that case, even for plain POD, alignment or endianness could easily screw you up.

In any case, you should be avoiding this kind of thing, if possible. Even if it works fine now, if you (or anybody else who doesn't understand that you're doing this trick) ever changes the structure order or adds new fields, this trick will fail in all the places you've used it, which may be hard to find.

Answer to your edit: If that's your entire class definition, and you're using one of the mainstream compilers with default options, and running on an x86 processor, then yes, you've probably guessed the right memory layout. But choice of compiler, compiler options, and different CPU architecture could easily invalidate your assumptions.

Answer 5

It really depends on the compiler, or rather, it is left up to the compiler to determine the memory layout.

For instance, a mix of public, private, and protected member variables could be layed out such that each access type is contiguous. Or, derived classes could have member variables interleaved with unused space in the super class.

Things get worse with virtual inheritance, where the virtually inherited base classes can be layed out anywhere in the memory allocated for that particular instance.

POD is different because it needs to be compatible with C.

MSN