有点学术问题，但是：像Int这样的值类型实际上工作？
我在mscorlib上使用了Reflector来了解System.Int32是如何实现的，它只是一个继承自System.ValueType的Struct。我正在寻找持有该值的数组的行中的某些东西，但我只发现了一个声明为int的字段 - 这意味着它是一个循环引用？
我的意思是，我可以写“int i = 14;”，但是数字14需要以某种方式存储在某处，但我找不到“32位数组”或指针等等。
这是编译器的一些魔力吗？这些魔术类型是规范的一部分吗？ （类似于System.Attribute或System.Exception是“特殊”类型）
编辑：如果我声明自己的结构，我会向其添加字段。这些字段是内置类型，例如int。所以CLR知道我持有一个int。但它如何知道int是32位，签名？仅仅是规范指定了某些基本类型并因此使它们“神奇”，还是有技术机制？假设示例：如果我想声明一个Int36，即36位的整数，我可以通过指定“创建一个类似于Int32的类型 （除了4个额外的位）好的，留出36位“，或者内置的原语是否一成不变，我必须以某种方式解决这个问题（即使用Int64和仅设置最后36位的代码）？
如上所述，所有这些都是非常学术性和假设性的，但我总是对此表示不满。
答案 0 :(得分：3)
某些基本类型（如整数）是CLI规范的一部分。例如，有像ldc.i4这样的特定IL指令用于加载这些类型的值，而诸如add之类的IL指令具有这些类型的特定知识。 （您的int i = 14示例将编译为ldc.i4 14，其中14代表内部编译的MSIL中的操作码的一部分。）
有关详细信息，请参阅CLI spec的分区IIa，第7.2节“内置类型”。 （对不起，找不到特定部分的链接。）内置类型是：bool，char，object，string，float32，float64，int [8 | 16 | 32 | 64]，unsigned int [8 | 1632 | 64]，native int（IntPtr），native unsigned int和typedref。该规范指出它们“具有在基类库中定义的相应值类型”，这使我认为Int32实际上是围绕“真实”int32的元数据包装器，它位于VES级别。
其他值类型，如System.Decimal，System.Drawing.Point或您在自己的代码中定义的任何结构，都是非魔法的。
答案 1 :(得分：1)
Int32是一种编译器内在类型，这意味着编译器具有处理它的特殊逻辑。在框架中实际实现Int32是没有意义的。
值得注意的是Int16，Int32，UInt16，UInt32，Single，Double等大致对应于x86指令集（和其他）本机的类型。创建Int36类型同样需要使用本机类型作为纯汇编代码的基础。