CLR 级别的强制转换实际上是如何工作的?
当进行向上或向下的拍摄时,幕后到底发生了什么?我的想法是,当执行以下操作时:
string myString = "abc";
object myObject = myString;
string myStringBack = (string)myObject;
最后一行中的强制转换的唯一目的是告诉编译器我们是安全的,我们没有做任何错误的事情。所以,我的想法是,实际上代码本身不会嵌入任何转换代码。看来我错了:
.maxstack 1
.locals init (
[0] string myString,
[1] object myObject,
[2] string myStringBack)
L_0000: nop
L_0001: ldstr "abc"
L_0006: stloc.0
L_0007: ldloc.0
L_0008: stloc.1
L_0009: ldloc.1
L_000a: castclass string
L_000f: stloc.2
L_0010: ret
为什么 CLR 需要像 castclass string
这样的东西?
向下转型有两种可能的实现:
- 您需要一个
castclass some
。当您到达执行castclass
的代码行时,CLR 会尝试进行转换。但是,如果我省略了castclass字符串行并尝试运行代码,会发生什么? - 您不需要
castclass
。由于所有引用类型都有相似的内部结构,如果您尝试在 Form 实例上使用字符串,它将抛出错误使用的异常(因为它检测到 Form 不是字符串或其任何子类型)。
另外,C# 4.0 in a Nutshell 中的以下陈述是否正确?
Upcasting and downcasting between compatible reference types performs reference
conversions: a new reference is created that points to the same object.
它真的创造了新的参考吗?我认为它是相同的引用,只是存储在不同类型的变量中。
谢谢
When doing an upcast or downcast, what does really happen behind the scenes? I had the idea that when doing something as:
string myString = "abc";
object myObject = myString;
string myStringBack = (string)myObject;
the cast in the last line would have as only purpose tell the compiler we are safe we are not doing anything wrong. So, I had the idea that actually no casting code would be embedded in the code itself. It seems I was wrong:
.maxstack 1
.locals init (
[0] string myString,
[1] object myObject,
[2] string myStringBack)
L_0000: nop
L_0001: ldstr "abc"
L_0006: stloc.0
L_0007: ldloc.0
L_0008: stloc.1
L_0009: ldloc.1
L_000a: castclass string
L_000f: stloc.2
L_0010: ret
Why does the CLR need something like castclass string
?
There are two possible implementations for a downcast:
- You require a
castclass something
. When you get to the line of code that does ancastclass
, the CLR tries to make the cast. But then, what would happen had I ommited the castclass string line and tried to run the code? - You don't require a
castclass
. As all reference types have a similar internal structure, if you try to use a string on an Form instance, it will throw an exception of wrong usage (because it detects a Form is not a string or any of its subtypes).
Also, is the following statamente from C# 4.0 in a Nutshell correct?
Upcasting and downcasting between compatible reference types performs reference
conversions: a new reference is created that points to the same object.
Does it really create a new reference? I thought it'd be the same reference, only stored in a different type of variable.
Thanks
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
一个有趣的想法。您认为这会如何发挥作用?
如果转换没有产生任何代码,那么引发异常的代码在哪里发生?
请记住,从不太具体的类型转换为更具体的类型的主要目的是执行运行时类型检查。
一旦类型检查通过,那么当然,就不需要发生其他事情了。类型检查之前的引用的位和类型检查之后的位是相同的位;我们刚刚让运行时验证旧位的新使用是否合理。
它在哪里检测到这一点?我的意思是,到底是在哪条指令中检测到的? 在castclass指令中。这就是castclass 指令的用途。
类型安全验证程序会拒绝您的程序。如果您在未通过验证的情况下强制 CLR 运行它,那么它将会出现未定义的行为。它可能成功了,也可能失败了,也可能格式化了你的硬盘。
请记住,在实现级别,引用只是一个指针大小的整数。内存管理器可以使用它来跟踪所引用数据的位置。它可能是一个指针,也可能是一个句柄,不管它是什么;它实现了引用的抽象概念。
当你有一个包含 12 的变量,并且用 12“替换”其内容时,这是刚刚创建的“新”12 还是“旧”12?假设您创建了第二个变量,并通过复制第一个变量将 12 也放入其中。这是“新”12 还是“旧”12?你怎么知道?这是一个没有区别的区别。当您创建与“旧”参考相同的“新”参考时,是否在创建新内容?这个问题是一个哲学问题,而不是一个技术问题。
An interesting idea. How did you imagine that this worked?
If the cast produces no code then where does the code that throws the exception happen?
Remember, the primary purpose of a cast from a less specific type to a more specific type is to perform a runtime type check.
Once the type check passes, then sure, nothing else really has to happen. The bits of the reference before the type check and the bits after the type check are the same bits; we've just had the runtime verify that the new usage of the old bits is justified.
Where does it detect that? I mean, in exactly which instruction is that detected? In the castclass instruction. That's what the castclass instruction is for.
The type safety verifier would have rejected your program. Had you forced the CLR to run it without passing verification then it would have had undefined behaviour. It might have succeeded, it might have failed, it might have formatted your hard disk.
Remember, at the implementation level a reference is just a pointer-sized integer. It's a number that the memory manager can use to track the position of the referred-to data. It might be a pointer, it might be a handle, it doesn't matter what it is; it's something that implements the abstract notion of a reference.
When you have a variable that contains 12 and you "replace" its contents with 12, is that a "new" 12 that has just been created or is it the "old" 12? Suppose you make a second variable and put 12 in it too by copying from the first variable. Is that a "new" 12 or the "old" 12? How can you tell? It's a difference that makes no difference. When you make a "new" reference that is identical to an "old" reference is that creating something new? The question is a philosophical question, not a technical one.
您将引用与实例混淆了。创建一个新的引用,而不是一个新实例。
对字符串
"foo"
的一个新引用被分配给baz
变量(但该字符串仍然只有一个实例,它只是两个变量都指向单个实例)。如果不是这种情况,您将拥有类似于“句柄”类型的东西。如果baz
和foo
实际上是相同的引用,那么这..也会使
baz
等于"bim"
(同样,分配非字符串类型将使 baz 不再指向有效的字符串引用)。当引用类型处于同一继承层次结构(一个直接或间接继承另一个引用类型)时,或者当类型之间存在显式转换时,您可以对引用类型执行强制转换。请注意,与所有其他运算符一样,显式转换不是多态的 - 也就是说,转换必须在相关类之一上专门定义,而不是在层次结构中的另一点上。
显式转换(如果存在)将优先,即使相关类型在没有显式转换的情况下也兼容。在显式转换的情况下,您无法保证(事实上,这是不太可能的)转换/转换的结果将指向与被转换的对象相同的实例。
You're confusing reference with instance. A new reference is created, not a new instance.
A new reference to the string
"foo"
is assigned to thebaz
variable (but there is still only one instance of the string, it's just that both variables point to the single instance). Were this not the case, you would have something akin to a "handle" type. Ifbaz
andfoo
were literally the same reference, then this..Would also make
baz
equal to"bim"
(likewise, assigning a non-string type would makebaz
no longer point to a valid string reference).You can perform a cast on a reference type either when they're in the same inheritance heirarchy (one inherits from the other either directly or indirectly) or when an explicit conversion between the types exists. Note that explicit conversions, like all other operators, are not polymorphic -- that is, the conversion must be defined specifically on one of the classes in question, not at another point in the heirarchy.
An explicit conversion, when present, will take priority even if the types in question are compatible without it. In the event of an explicit conversion, you have no guarantee (in fact, it's quite unlikely) that the result of the cast/conversion will point to the same instance as the object being cast.