Skip to content

Latest commit

 

History

History
65 lines (33 loc) · 4.82 KB

ii.22.8-classlayout-0x0f.md

File metadata and controls

65 lines (33 loc) · 4.82 KB

II.22.8 ClassLayout: 0x0F

The ClassLayout table is used to define how the fields of a class or value type shall be laid out by the CLI. (Normally, the CLI is free to reorder and/or insert gaps between the fields defined for a class or value type.)

[Rationale: This feature is used to lay out a managed value type in exactly the same way as an unmanaged C struct, allowing a managed value type to be handed to unmanaged code, which then accesses the fields exactly as if that block of memory had been laid out by unmanaged code. end rationale]

The information held in the ClassLayout table depends upon the Flags value for {AutoLayout,SequentialLayout, ExplicitLayout} in the owner class or value type. A type has layout if it is marked SequentialLayout or ExplicitLayout. If any type within an inheritance chain has layout, then so shall all its base classes, up to the one that descends immediately from System.ValueType (if it exists in the type's hierarchy); otherwise, from System.Object.

This contains informative text only.

Layout cannot begin part way down the chain. But it is valid to stop "having layout" at any point down the chain. For example, in the diagrams below, Class A derives from System.Object; class B derives from A; class C derives from B. System.Object has no layout. But A, B and C are all defined with layout, and that is valid.

Valid layout setups

The situation with classes E, F, and G is similar. G has no layout, and this too is valid. The following picture shows two invalid setups:

Invalid layout setups

On the left, the "chain with layout" does not start at the 'highest' class. And on the right, there is a 'hole' in the "chain with layout".

Layout information for a class or value type is held in two tables (ClassLayout and FieldLayout), as shown in the following diagram:

ClassLayout and FieldLayout

In this example, row 3 of the ClassLayout table points to row 2 in the TypeDef table (the definition for a Class, called "MyClass"). Rows 4-6 of the FieldLayout table point to corresponding rows in the Field table. This illustrates how the CLI stores the explicit offsets for the three fields that are defined in "MyClass" (there is always one row in the FieldLayout table for each field in the owning class or value type) So, the ClassLayout table acts as an extension to those rows of the TypeDef table that have layout info; since many classes do not have layout info, overall, this design saves space.

End informative text.

The ClassLayout table has the following columns:

  • PackingSize (a 2-byte constant)

  • ClassSize (a 4-byte constant)

  • Parent (an index into the TypeDef table)

The rows of the ClassLayout table are defined by placing .pack and .size directives on the body of the type declaration in which this type is declared (§II.10.2). When either of these directives is omitted, its corresponding value is zero. (See §II.10.7.)

ClassSize of zero does not mean the class has zero size. It means that no .size directive was specified at definition time, in which case, the actual size is calculated from the field types, taking account of packing size (default or specified) and natural alignment on the target, runtime platform.

This contains informative text only.

  1. A ClassLayout table can contain zero or more rows

  2. Parent shall index a valid row in the TypeDef table, corresponding to a Class or ValueType (but not to an Interface) [ERROR]

  3. The Class or ValueType indexed by Parent shall be SequentialLayout or ExplicitLayout (§II.23.1.15). (That is, AutoLayout types shall not own any rows in the ClassLayout table.) [ERROR]

  4. If Parent indexes a SequentialLayout type, then:

    • PackingSize shall be one of {0, 1, 2, 4, 8, 16, 32, 64, 128}. (0 means use the default pack size for the platform on which the application is running.) [ERROR]

    • If Parent indexes a ValueType, then ClassSize shall be less than 1 MByte (0x100000 bytes). [ERROR]

  5. If Parent indexes an ExplicitLayout type, then

    • if Parent indexes a ValueType, then ClassSize shall be less than 1 MByte (0x100000 bytes) [ERROR]

    • PackingSize shall be 0. (It makes no sense to provide explicit offsets for each field, as well as a packing size.) [ERROR]

  6. Note that an ExplicitLayout type might result in a verifiable type, provided the layout does not create a type whose fields overlap.

  7. Layout along the length of an inheritance chain shall follow the rules specified above (starting at 'highest' Type, with no 'holes', etc.) [ERROR]

End informative text.