Data alignment which result in better performance.
This is common to many languages even outside of .NET world.

Could you tell us how you're measuring this size?

Jon

It's up to the CLR, not the language.  Object layout is simply not a
language concept in .NET.

This is exactly what I'd expect from C or C++: the struct is a multiple of
the most restritive alignment, in this case, the int has an alignment of 4,
so the size is a multiple of 4.

Again, the size is a multiple of the most restrictive alignment.  double has
an alignment of 8, so the size is a multiple of 8.

And again, it must be a multiple of 8, but you've added data beyond byte 16,
so the size bumps up to 24 to maintain alignment.

Alignment, Alignment, Alignment.  It's exactly the sizes that these structs
would have in C/C++ with VC++ (or most any 32-bit C or C++ compiler).

If you need to control struct layout, you can do so explicitly using the
StructLayout and FieldOffset attributes in the
System.Runtime.InteropServices namespace.

-cd

Guess you are using Marshal.SizeOf(..) to determine the size of a struct,
however, this function returns the 'marshaled' size, which is not
necessarily the same as the size in memory as it is subject to alignment and
padding. Note that the CLR controls the layout of any managed object in
memory, you can only control the layout as it would appear at the unmanaged
side when marshaling the object (struct or class). Check
StructLayoutAttribute in the docs, the LayoutKind.Explicit enum allows you
to control the layout (and thus the size of the marshaled struct) from your
code instead of using the default (LayoutKind.Sequential).

Willy.

The memory is aligned on 8-byte boundaries. There are a bunch of reasons for
this (mainly for performance), just do a search on Google and you should
find it. You can change it using the StructLayoutAttribute.

  /claes

It has to do with alignment.

Remember that the CLR is designed to run on  multiple CPU architectures.
On 32 bit machines, the hardware is usually optimized to fetch data from
memory addresses that are a multiple of 4. So suppose you (somehow) had
a reference to a struct at address 0 (in really,  really low memory)
[Side note: null pointers in C/C++ are so common that Windows makes low
memory unavailable for even reading, to help debugging].

If your struct had { char c; int x; }, then naively you'd expect x to be
at memory address 2. But that would mean that the hardware would have to
fetch the 4 bytes from address 0 and remember the two bytes it needs
from there, then fetch the 4 bytes from address 4, and again grab two
bytes, and finally glue the two chunks together to give you the value of
x. Can't you just see your program slowing down tremendously if you did
this in an inner loop?

Indeed, on some CPU architectures, they don't support this at all. If
you tried to fetch a 32-bit value from an address that wasn't a multiple
of 4, the native machine language instruction would fault (roughly the
same way a DIVide opcode would fault if you tried to divide by zero).

And in some cases, doubles (8 byte fields) should/must be on 8-byte
address boundaries.

So in our above case, one way around this would be to insert two
internal pad bytes (uninitialized, unused) between c and x. If you've
ever done any C/C++ programming, you might be familiar with #pragma
pack, which does the same type of thing.

But now we have to take arrays into consideration. Take your struct S1,
with an int and a char. Yes it could fit into 6 bytes. But if you had an
array of them, while S1[0].x would be at address 0, S1[1].x would be at
address 6. Uh-oh. So let's pad each struct out to a multiple of 8, and
then things are guaranteed (well, depending on your CPU architecture;
it's not inconceivable that some day, on "Win-128", we might pad it out
to 16 byte multiples) to be aligned.

Uh, one more thing. The CLR doesn't necessarily do padding that way. It
assumes it can reorder your data fields (!!!). I recently wrote a reply
to someone else. See, in this newsgroup, my article "Re: Convert from
byte[] to structure value", posted 8/10/2006, 3:27PM.

And you thought struct's were simple! :-)