什么时候应该在C#中使用结构而不是类?我的概念模型是,当项只是值类型的集合时,使用结构。一种将它们逻辑地结合在一起的方法。

我在这里遇到了这些规则:

结构应表示单个价值结构应具有内存占用空间小于16字节。结构不应在之后更改创造

这些规则有效吗?结构在语义上意味着什么?


当前回答

Struct可用于提高垃圾收集性能。虽然您通常不必担心GC性能,但在某些情况下,它可能是一个杀手。就像低延迟应用程序中的大型缓存。请参阅本帖中的示例:

http://00sharp.wordpress.com/2013/07/03/a-case-for-the-struct/

其他回答

我不同意原帖子中给出的规则。以下是我的规则:

当存储在数组中时,可以使用结构来提高性能。(另请参见结构何时是答案?)在向C/C传递结构化数据的代码中需要它们++除非需要,否则不要使用结构:它们的行为与赋值下的“正常对象”(引用类型)不同当作为参数传递时,这可能导致意外行为;如果查看代码的人不知道他们正在处理一个结构。它们不能被继承。将结构作为参数传递比类更昂贵。

当您需要值语义而不是引用语义时,请使用结构。

如果需要引用语义,则需要类而不是结构。

除了“它是一个值”的答案之外,使用结构的一个特定场景是当您知道有一组数据会导致垃圾收集问题,并且您有很多对象时。例如,Person实例的大列表/数组。这里的自然隐喻是一个类,但如果您有大量长寿的Person实例,它们可能会阻塞GEN-2并导致GC暂停。如果场景允许,这里的一种潜在方法是使用Person结构的数组(而不是列表),即Person[]。现在,在GEN-2中没有数百万个对象,而是在LOH上有一个块(我假设这里没有字符串等-即没有任何引用的纯值)。这对GC的影响很小。

处理这些数据是很困难的,因为数据对于一个结构来说可能太大了,而且您不想一直复制胖值。然而,直接在数组中访问它不会复制结构-它是在适当的位置(与列表索引器不同,它会复制)。这意味着大量的索引工作:

int index = ...
int id = peopleArray[index].Id;

请注意,保持值本身不可变将有助于此。对于更复杂的逻辑,请使用带有by-ref参数的方法:

void Foo(ref Person person) {...}
...
Foo(ref peopleArray[index]);

同样,这是正确的-我们没有复制值。

在非常具体的情况下,这种策略可能非常成功;然而,这是一个相当先进的scernario,只有当你知道自己在做什么和为什么时,才应该尝试。这里的默认值是类。

不,我不完全同意这些规则。它们是考虑性能和标准化的良好指南,但不是根据可能性。

正如你在回答中看到的,有很多创造性的方法来使用它们。因此,这些指导原则需要做到这一点,始终是为了性能和效率。

在本例中,我使用类以更大的形式表示真实世界的对象,使用结构来表示具有更精确用途的较小对象。你说的是,“一个更具凝聚力的整体”。类将是更多面向对象的元素,而结构可以具有这些特性,尽管规模较小。IMO。

我在Treeview和Listview标签中经常使用它们,在这些标签中可以非常快速地访问常见的静态属性。我一直在努力以另一种方式获取这些信息。例如,在我的数据库应用程序中,我使用Treeview,其中包含表、SP、函数或任何其他对象。我创建并填充我的结构,将其放入标记中,将其拉出,获取所选内容的数据等等。我不会在课堂上这样做!

我确实会尽量缩小它们,在单实例情况下使用它们,并防止它们发生变化。注意内存、分配和性能是明智的。测试是非常必要的。

简单地说,如果:

您的对象财产/字段不需要更改。我的意思是你只想给它们一个初始值,然后读它们。对象中的财产和字段是值类型,它们并没有那么大。

如果是这种情况,您可以利用结构来获得更好的性能和优化的内存分配,因为它们只使用堆栈,而不是同时使用堆栈和堆(在类中)