为什么需要在结构体上调用 :this() 才能在 C# 中使用自动属性？

Question

如果我使用如下自动属性在 C# 中定义结构：

public struct Address
{
    public Address(string line1, string line2, string city, string state, string zip)
    {
        Line1 = line1;
        Line2 = line2;
        City = city;
        State = state;
        Zip = zip;
    }

    public string Line1 { get; protected set; }
    public string Line2 { get; protected set; }
    public string City { get; protected set; }
    public string State { get; protected set; }
    public string Zip { get; protected set; }
}

当我尝试构建文件时，我收到编译错误，提示 在将“this”对象的所有字段分配给之前，无法使用“this”对象 。 这可以通过更改构造函数以对默认构造函数进行链式调用来解决，如下所示：

public Address(string line1, string line2, string city, string state, string zip): this()
{
    Line1 = line1;
    Line2 = line2;
    City = city;
    State = state;
    Zip = zip;
}

我的问题是，为什么会这样，以及发生了什么？ 我有一个猜测，我试图通过查看 IL 来证明它，但如果我认为我可以分解 IL，那我只是在自欺欺人。 但我的猜测是，自动属性的工作原理是让编译器在幕后为您的属性生成字段。 这些字段无法通过代码访问，所有设置和获取都必须通过属性完成。 创建结构体时，不能显式定义默认构造函数。 因此，在幕后，编译器必须生成一个默认构造函数来设置开发人员看不到的字段值。

欢迎所有 IL 奇才来证明或反驳我的理论。

Answer 1

注意：从 C# 6 开始，这不是必需的 - 但无论如何，您应该在 C# 6 中使用只读自动实现的属性...

this() 使得确保就编译器而言，这些字段是明确分配的 - 它将所有字段设置为其默认值。 在开始访问任何属性之前，您必须拥有一个完全构造的结构。

这很烦人，但事实就是这样。 你确定你真的希望这是一个结构吗？ 为什么要在结构体上使用受保护的 setter（无法从中派生）？

Answer 2

属性只不过是 Get 方法和/或 Set 方法的封装。 CLR 具有元数据，指示特定方法应被视为属性，这意味着编译器应允许某些方法不允许的构造。 例如，如果 X 是 Foo 的读写属性，编译器会将 Foo.X += 5 翻译为 Foo .SET_X_METHOD(Foo.GET_X_METHOD() + 5) （尽管这些方法的命名不同，并且通常不能通过名称访问）。

尽管自动属性实现了一对 get/set 方法，这些方法以或多或少类似于字段的方式访问私有字段，但从属性外部的任何代码的角度来看，自动属性是一对 get/set 方法。设置方法就像任何其他属性一样。 因此，像 Foo.X = 5; 这样的语句会被翻译为 Foo.SET_X_METHOD(5)。 由于 C# 编译器仅将其视为方法调用，并且方法不包含任何元数据来指示它们读取或写入哪些字段，因此编译器将禁止方法调用，除非它知道 Foo 的每个字段已被写入。

就我个人而言，我的建议是避免将自动属性与结构类型一起使用。 自动属性对于类来说很有意义，因为类属性可以支持更新通知等功能。 即使类的早期版本不支持更新通知，让这些版本使用自动属性而不是字段也意味着未来的版本可以添加更新通知功能，而无需重新设计该类的使用者。 然而，结构无法有意义地支持人们可能希望添加到类字段属性中的大多数类型的功能。

此外，大型结构的字段和属性之间的性能差异比类类型的性能差异大得多。 事实上，许多避免大型结构的建议都是这种差异的结果。 如果避免不必要的复制，大型结构实际上可以非常高效。 即使有一个巨大的结构 HexDecet>>，其中 HexDecet 包含公开字段 F0 ..T 类型的F15，像 Foo = MyThing.F3.F6.F9; 这样的语句只需要从 读取一个整数>MyThing 并将其存储到 Foo，尽管 MyThing 按照结构标准会很大（4096 个整数占用 16K）。 此外，可以非常轻松地更新该元素，例如MyThing.F3.F6.F9 += 26;。 相比之下，如果 F0..F15 是自动属性，则语句 Foo = MyThing.F3.F6.F9 将需要复制 1K从 MyThing.F3 到临时文件（称为 temp1）的数据，然后从 temp1.F6 到 temp2 的 64 字节数据code>），然后最终从 temp2.​​F9 读取 4 个字节的数据。 恶心。 更糟糕的是，尝试将 26 添加到 MyThing.F3.F6.F9 中的值需要类似 var t1 = MyThing.F3; 的内容。 var t2 = t1.F6; t2.F9 += 26； t1.F6 = f2; MyThing.F3 = t1;。

许多关于“可变结构类型”的长期抱怨实际上是对具有读/写属性的结构类型的抱怨。 只需用字段替换属性，问题就会消失。

PS：有时，拥有一个其属性访问它所持有的引用的类对象的结构会很有用。 例如，如果有一个 ArraySegment 类的版本，允许人们说 Var foo[] = new int[100]; 那就太好了。 Var MyArrSeg = New ArraySegment(foo, 25, 25); MyArrSeg[6] += 9;，并让最后一条语句将 9 添加到 foo 的元素 (25+6) 中。 在旧版本的 C# 中可以做到这一点。 不幸的是，在框架中频繁使用自动属性（其中字段更合适）导致了对编译器允许在只读结构上无用地调用属性设置器的广泛抱怨； 因此，现在禁止在只读结构上调用任何属性设置器，无论属性设置器是否实际上会修改结构的任何字段。 如果人们只是避免通过属性设置器使结构可变（当可变性合适时使字段可直接访问），编译器将永远不必实现该限制。