readonly struct成员和普通struct成员用起来有什么区别?

http://blogs.msdn.com/b/ericlippert/archive/2008/05/14/mutating-readonly-structs.aspx

这篇文章的代码令我吃了一惊。居然真的是每次访问t.m都拷贝了一次(从IL上看,编译器专门加了一个局部变量,每次访问都会把readonly的成员从新放进去)。
但是作者的说法“accessing a value type gives you a COPY of the value.”是不正确的。
评论中的说法更准确:

There are only two rules here:

1) Readonly fields are not variables.

2) Accessing anything on a value type which is not a variable acts on a copy of the value type.

把代码里的readonly去掉,就能得到1,2,3的运行结果,这次当struct是一个普通的变量成员的时候,就不会每次访问都拷贝一次了。

(这和传递参数的时候strcut是值传递是两个独立的概念,这里完全不涉及参数传递)

另外,我个人觉得非要强调struct不能改变是不合理的,支持Frederik Siekmann的做法,虽然楼主认为他这种情况应该用类而不是用struct.

ldarg.0 到底是把第几个参数压入堆栈?

0当然代表第0个位置上的参数,但究竟是哪个呢? 答案是:instance方法的话第0个参数实际上是自己(this),static的方法则第0个参数就是真正看到的第一个参数。或者这么记,不管instance还是static,第0个参数永远是调用者传递的第一个参数(感觉有点怪)

http://en.m.wikipedia.org/wiki/Closure_(computer_science)
这就是上面说的闭包的概念。
C#语言里还有一个类型涉及到闭包,可以顺便记忆:
就是delegate, 作为继承自delegate类的引用类型,delegate实际有两种
http://blog.slaks.net/2011/06/open-delegates-vs-closed-delegates.html
但默认的使用delegate都是closed delegate, 你必须用create delegate方法来创建一个open delegate.
Lambda表达式是编译器帮助程序员自动生成delegate的语法(有时也生成表达式expression), 在生成delegate时,同样默认是生成为closed delegate.
这就带来了一个潜在的问题:
Lambda用爽了,很容易出现delegate中的引用问题(你自己都没注意编译器就又帮你生成了一个delegate),他们可都是closed的。下面的贴子是问题的根本,出问题的时候是我们出现了delegate中的delegate,
在没有把下一层的delegate(onsuccess, onfail)置空值释放掉的情况下,又保持着当前方法的delegate一直在内存里。
http://stackoverflow.com/questions/8417470/private-field-captured-in-anonymous-delegate

用几个实例的类来说明struct和class的概念

本来CLR里所有东西都是class,从system.object下来的。
但是中间插了个ValueType类,CLR又对它特殊对待,而所有Strcuts都继承自ValueType.
也都是传值而不穿引用。
很容易引起误会,把ValueType和Structs等同起来(因为元类型int,double等也是strcuts,也是ValueType)
但是这里enum是一个例外。他是一个传值的东西(valueType),但是它真不是struct.
 

Structs are not really a CLR notion — value types are. Part of the confusion
here is that the term “struct” and “value type” are being passed around as
synonomous — which they really aren’t. All C# structs are value types but
not all value types are C# structs.

At the CLR level, there are only classes. In fact, interfaces are actually
classes too but have a specific bit set that denotes them as interfaces and
causes them to be treated differently. A value type is simply a class that
derives from System.ValueType. An enum is a class that derives from System.Enum
(which derives from System.ValueType). The CLR simply treats classes that
derive from System.ValueType in a special way — passing them by value instead
of by reference and allocating them on the stack when declared in a method
body.

Lutz Roeder’s reflector can be a bit misleading if you leave the language
set to C#. Setting it to IL will show the reality of how types are really
declared. Consider this declaration of System.Int32 in IL:

..class public sequential ansi serializable sealed beforefieldinit Int32
extends System.ValueType
implements System.IComparable, System.IFormattable, System.IConvertible,
System.IComparable`1<int32>, System.IEquatable`1<int32>

It is really a class that derives from System.ValueType and implements a
set of specific interfaces. There is nothing remarkably different about how
System.Int32 is declared versus, say, System.StringComparer:

..class public abstract auto ansi serializable beforefieldinit StringComparer
extends object
implements System.Collections.IComparer, System.Collections.IEqualityComparer,
System.Collections.Generic.IComparer`1<string>, System.Collections.Generic.IEqualityComparer`1<str ing>

The only difference is the base type that it derives from. Enums are no different
— consider System.StringComparison:

..class public auto ansi serializable sealed StringComparison
extends System.Enum

Enums *are* classes at the CLR level. Reflection attempts to make distinctions
between different types to clarify them for the client. So, it is not a great
tool to use to try and understand how things are really put together at the
metadata-level.

>System.Enum derives from System.ValueType.

Which does not necessarily make it a structure.

You’re correct, it makes it a value type. Clarification of terminology is
definitely needed here.