Why does my object take up 64 bytes and not 32?

Question

I have a class that goes like this:

class myType
{

  union {
      float data[4];
      other_vector4_type v
  } ;
  typedef union {
      float data[4];
      other_vector4_type v
  } myType-internal_t;

 <various member functions, operator overloads>

}

Now I want to use this type in my vertex buffer, but the sizeof() isn't as expected. I aligned the class to 16 bytes.

sizeof(myType) yields 64.

sizeof(myType::myType-internal_t) yields 32.

I've read quite a few articles on data alignment but I don't know where I'm using extra data. I tried stripping out the custom constructor but it remains the same, swapping the class keyword for struct doesn't change it either (I don't understand what it's for, as it happens!)

This is annoying, I'll use the internal type for now since I won't be touching the data often, but it would be great to have the class work like I want.

Answer 1

A C++ compiler can make that struct 128 bytes for all it cares. The size of structs/unions is not defined by the C++ standard. However, most compilers have a nonstandard __PACKED attribute you can add to the declaration of a struct and it will take up only the exact amount of bytes that it needs

Answer 2

If you have virtual functions in your class it will make your objects bigger than the internal type because of the vtable pointer.

BTW "struct { " is just the same as saying "class { public : "

Answer 3

I imagine you will have a vtable pointer defined for your objects. Either because you have RTTI enabled or any virtual method (including the destructor) will add a vtable

http://en.wikipedia.org/wiki/Virtual_method_table

Typically, the compiler creates a separate vtable for each class. When an object is created, a pointer to this vtable, called the virtual table pointer or vpointer, is added as a hidden member of this object (becoming its first member unless it's made the last[2]). The compiler also generates "hidden" code in the constructor of each class to initialize the vpointers of its objects to the address of the corresponding vtable.

Answer 4

I just compiled

#include <xmmintrin.h>
#include <iostream>

struct myType
{
    union {
        float data[4];
        __v4sf v;
    };
    typedef union {
        float data[4];
        __v4sf v;
    } myType_internal_t;
};

int main() {
    std::cout << sizeof(myType) << std::endl;
    std::cout << sizeof(myType::myType_internal_t) << std::endl;
}

And the result is:

16
16

using gcc on a 64 bit arch. As expected. "__v4sf" is a vector type consisting of four floats. So the problem is probably in your "other_vector_4_type". Maybe it is polymorphic and virtual and contains two vtables? And you are using more virtual functions in "myType" which increase its size further? The problem may be related to your compiler or the architecture too.

Answer 5

Nope, I don't have a vtable pointer, nothing virtual. I read about a tool to dump object layout data, is there a good free one?

Sorry, forgot to add that I'm using vc++2008 express. I tried wrapping it in a struct, no changes.

@bmargulies and Charles Salvia- irrelevant as I'm getting 32 for the internal struct, no? :P

The problem I face is that the class is somehow adding an overhead to the struct (which works fine, in debug I can see the data and modify it as I like)

@jalf- aha, it was _ but _i starts italics.

drhirsch, thanks, I am using 64bit but compiling for win32, here is what I have now:

class myType
{
public:
    union {
        float data[4];
        other_vector4_type v;
    };
    typedef union {
        float data[4];
        other_vector4_type v;
    } myType_internal_t;
};

And I am getting 32 (16 for the above sample) (I should have mentioned, I'm checking size of myType*2 and another type that has 2 of them.)

So I was initially right, my class is adding some overhead to it, but it's not virtual and doesnt inherit from anything! So the answer lies in the methods I'm using..

Answer 6

Well that's weird, it seems to work fine now (16 bytes with a custom ctor) so I'll search-and-destroy the culprit method !

Thanks for all the fast replies/help, you inspired me!

@Michael Burr- true, and I just noticed ajax updates comments.. this gives more impact though.