Geek Answers Handbook

C ++ Sizeof gives unpredictable results

Possible duplicate:
Why does sizeof give the wrong measurement?

I have a CBUFFER_PEROBJECT structure:

struct CBUFFER_PEROBJECT { D3DXMATRIX Final; D3DXMATRIX Rotation; };

And in another class I do this:

 ... bd.ByteWidth = sizeof(CBUFFER_PEROBJECT); ...

I found out that the size of D3DXMATRIX is 64, so 64 + 64 = 128 (on the right?). But my compiler plays with me (Visual C ++), because when I debugged the program, bd.ByteWidth became 132, so I went to the Immediate window (Visual Studio) and typed:

 sizeof(D3DXMATRIX) + sizeof(D3DXMATRIX)

And the result:

 128

But bd.ByteWidth became 132, and when I enter the following into the "Immediate Window":

 sizeof(CBUFFER_PEROBJECT)

This gives me:

 128
+4
source share
5 answers

Sometimes, when compilers evaluate structure declarations, they add padding bytes between fields. This is because some types work better if they match memory addresses that are multiples of their length.

I would say that very soon you will not see this effect in the next window.

Given these grounds, this is a duplicate question. You can get a more detailed answer here: Why is the sizeof size for the structure not equal to the sum of the sizeof of each member?

+2
source

That's right, you confuse D3DMATRIX and D3DXMATRIX (note the extra X in the second type). The first is a simple matrix of 16 float values ​​(exactly 64 bytes). The latter is a class, and it obviously has 4 bytes of extra data somewhere in the structure. Perhaps vtable or some such.

If you compile the code as C, not C ++, the size will be the same as the header file containing the last of the structures, and then typedef D3DMATRIX D3DXMATRIX; .

See: D3DXMATRIX and D3DMATRIX

Edit: This is a bit like an old joke about war words: "If the map and reality do not match, the map is correct." In this case, if you do not agree with the compiler, you are mistaken. When calculating sizes, the compiler is ALWAYS ALWAYS. Understanding WHY the compiler got this number, well, that’s another matter ... Usually they are solved by comparing the expected displacements in the structure with what is actually happening, and understanding that if something caused “gaps”.

+6
source

You cannot calculate the size of a structure by simply calculating its element sizes, because it also stores some additional information (not visible to the programmer) in the structures. That is why you get 132 instead of 128.

+2
source

In this case, it is better to assume that the compiler is correct. Most likely, this means that you have two different CBUFFER_PEROBJECT definitions in your project with slightly different definitions. The compiler considers that definition A is size 132, while the debugger considers definition B of size 128. You can verify this by creating global variables containing the sizeof(CBUFFER_PEROBJECT) value sizeof(CBUFFER_PEROBJECT) in each source file. You can then check these globals in the debugger to see what it shows.

Another possibility is, of course, that your memory is overwritten and NOT set by the line that you think it sets up. In this case, something like Purify or valgrind can help you track down the memory issue.

+1
source

You can use the hidden visual studio compiler switch in / d1reportSingleClassLayoutSomeType to tell you what the compiler layout is. Follow the link to read how to use the switch.

I tried this for your sample code, but I don't have the type "D3DXMATRIX". I have "D3DMATRIX", so I tried this and got:

 1> class CBUFFER_PEROBJECT size(128): 1> +--- 1> 0 | _D3DMATRIX Final 1> 64 | _D3DMATRIX Rotation 1> +---

So, if you are using a switch, it should be able to tell you the exact layout of your structure.

+1
source

More articles:


All Articles