是列表吗?一个指针?
我注意到 List
的行为与其他简单对象(例如 String
)不同。这个问题看起来很新手,但这确实让我震惊,因为我认为 List
是简单的对象。
以下面的代码为例:
List<String> ls1 = new List<String>();
ls1.Add("a");
List<String> ls2 = ls1;
ls1.Add("b");
最后,ls1
将等于 {"a", "b"}
,ls2
也将等于。这与此代码的行为确实不同:
String s1 = "a";
String s2 = s1;
s1 = "b";
其中 s1
最后等于 b
且 s2
等于 a< /代码>。
这意味着 List
实际上是一个指针,对吗?
I noticed that the behavior of List<T>
is different from an other simple object, say String
for example. The question can seem newbie but that really struck me cause I thought that List<T>
were simple objects.
Take for instance the following code:
List<String> ls1 = new List<String>();
ls1.Add("a");
List<String> ls2 = ls1;
ls1.Add("b");
At the end, ls1
will be equal to {"a", "b"}
and so will ls2
. This is really different from the behavior of this code:
String s1 = "a";
String s2 = s1;
s1 = "b";
Where s1
is at the end equal to b
and s2
equal to a
.
That means that List<T>
is in fact a pointer right?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
List
一个引用类型,所以它的行为就像一个指针。String
也是一种引用类型,但字符串是不可变的,并且在某些情况下它们的行为类似于值类型(与引用类型对比),因此您会感到困惑。这里有一个很好的解释为什么字符串以这种方式工作: 在 C# 中,为什么 String 是一种行为类似于值类型的引用类型?
List<T>
a reference type, so yes it behaves like a pointer.String
is also a reference type, but strings are immutable and they behave like value types (contrast with reference types) in some cases hence your confusion here.There is a good explanation of why string work this way here: In C#, why is String a reference type that behaves like a value type?
s1 = "b"
行实际上为s1
分配了一个新引用。s1
和s2
现在引用两个不同的对象。对
ls1
引用的List
对象的更改通过对该对象的所有引用(包括ls2
)可见。当您创建ls2 = ls1
时,您基本上是在说ls1
和ls2
引用同一个对象。通过引用变量 ls1 对对象所做的更改可以通过引用变量 ls2 看到。The line
s1 = "b"
actually assigns a new reference tos1
.s1
ands2
now refer to two different objects.The changes to the
List<string>
object referred to byls1
are visible through all references to that object, includingls2
. When you makels2 = ls1
you are basically saying that bothls1
andls2
refer to the same object. Changes to the object via the reference variablels1
are visible via the reference variablels2
.在 C# 中,它们称为
引用
,而不是指针
。可能它们是同一件事,只是减去了不能将它们转换为整数来打印它们的事实,并减去了被禁止的指针算术。从技术上讲,它们是“不透明的”,所以你不(不应该)知道它们是如何工作的。显然,如果您使用托管 C++,这种不透明性就会被打破:-)In C# they are called
references
, notpointers
. Probably they are the same thing minus the fact that you can't cast them to an integer to print them and minus the pointer arithmetic that is forbidden. Technically they are "opaque", so you don't (shouldn't) know how they work. Clearly this opaqueness is broken if you use Managed C++ :-)C# 中的每个对象都是一个引用。像 int、
string、char 这样的基元不是引用。Every object in C# is a reference. Primitives like int,
string, char, are not references.String、int、float 都是值类型。因此,当您说
当 s2 初始化时,s1 的值将复制到分配给 s2 的空间中。因此,如果您正在窥探内存,您可以在内存中的两个不同位置(分配给 s1 的位置和分配给 s2 的内存)找到“a”的十六进制表示形式。但是,如果您尝试对引用类型(例如 List)执行相同的操作,那么当您说这样的内容是按引用传递时会发生什么:
具有与在堆上分配的 List 相对应的对象。查找该对象的地址驻留在为局部变量 s1 和 s2 分配的空间上,而不是驻留在该空间中的实际值。原因是对象(List)可能很大,并且在程序的生命周期中可能存在很长时间,并且为这样的对象从堆栈中分配内存将是昂贵的。
我建议您阅读这个问题线程,以了解有关 CLR 如何真正解释值类型和引用类型的更多信息
String, int, float are all value types. So, when you say
When s2 is initialised, the value of s1 is copied into the space allocated to s2. So, if you were snooping on the memory, you could find the hex representation of "a" at two distinct locations in the memory(the location allocated to s1 and the memory allocated to s2). But if you try to do the same with a reference type, like List, what happens when you say something like this is a pass by reference:
is that have the object corresponding to the List allocated on the heap. The address of where to find this object resides on the space allocated for the local variables s1 and s2 instead of the actual value residing in that space. The reason is that the object(List) might be a large one and potentially long lived through the life of the program and it would be expensive to allocate memory off the stack for such an object.
I recommend you read this question thread to understand more about how value types and reference types are really interpreted by the CLR