27

Why can't I use sizeof() on simple structs?

eg:

private struct FloatShortPair
{
    public float myFloat;
    public short myShort;
};

int size = sizeof(FloatShortPair);  //CS0233

error CS0233: 'FloatShortPair' does not have a predefined size, therefore sizeof can only be used in an unsafe context (consider using System.Runtime.InteropServices.Marshal.SizeOf)

MSDN states:

The sizeof operator can only be used for types that are compile-time constants. If you are getting this error, make sure that the size of the identifier can be determined at compile time. If it cannot, then use SizeOf instead of sizeof.

How are float and short not compile time constants? 8-/

GazTheDestroyer
  • 20,722
  • 9
  • 70
  • 103

1 Answers1

27

The sizes of short and float are constant - but how the CLR decided to pack that float in memory isn't necessarily constant. For example, on a 64-bit processor it may decide to align each value on an 8-byte boundary.

From the C# 4 spec, section 18.5.8:

For certain predefined types, the sizeof operator yields a constant value as shown in the table below.

[...]

For all other types, the result of the sizeof operator is implementation-defined and is classified as a value, not a constant.

[...]

For alignment purposes, there may be unnamed padding at the beginning of a struct, within a struct, and at the end of a struct.

Note that you can use sizeof in this situation, within an unsafe context. Whether you should use that or Marshal.SizeOf depends on what you're trying to do.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 1
    As the error message suggests use System.Runtime.InteropServices.Marshal.SizeOf. – Mongus Pong Nov 08 '11 at 09:57
  • 2
    Related question (sorry to hijack): If you have finer control over the layout of the type (StructLayoutAttribute with explicit offsets) does that make it a compile time constant? – MattDavey Nov 08 '11 at 10:07
  • 1
    @MattDavey: Not according to the spec. Basically the C# language specification tries not to get into the implementation details of things like StructLayoutAttribute. – Jon Skeet Nov 08 '11 at 10:11
  • If one wanted to optimize an `IList` implementation for scenarios where many moderate-sized lists would be created, used briefly, and abandoned, keeping all arrays small enough to avoid LOH allocations would be a major win. By what means should a class choose the maximum inner array size if it can't find out the actual amount of space .NET will require for each element? – supercat Jun 14 '13 at 15:09
  • I know that the process for deciding what objects should go on the LOH could change, but keeping arrays below 85,000 bytes would improve performance at least on today's version of .NET; even if some other strategy might be better in a future .NET, code which keeps allocations below 85,000 bytes should continue to at least work decently. But to make code keep allocations below 85,000 bytes with today's .NET, it would have to know their size with today's .NET. – supercat Jun 14 '13 at 15:12
  • Is there a way to explicitly state how the CLR should pack that data in memory? – Aaron Franke Mar 16 '21 at 02:24
  • @AaronFranke: Yes, with `[StructLayout]`. See https://learn.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.structlayoutattribute?view=net-5.0 – Jon Skeet Mar 16 '21 at 06:42