不从 System.Object 继承之后

 

Written by Allen Lee

 

上一篇文章说到 IL 允许创建一个不继承自 System.Object 的类,这打破了我们已有的一些认识。到了这个份上,我们自然会追问,为什么要允许这种类型存在呢?

考察如下 C++/CLI 代码:

 1不从 System.Object 继承之后using namespace System;
 2不从 System.Object 继承之后
 3不从 System.Object 继承之后public ref class Person
 4}

DisplayPersonInfo 方法只能用在 C++/CLI 中,你无法在 C# 中对引用类型进行解引用,就像第三十六行那样。为了处理 C++/CLI 的特性,IL 引入了不少别的语言无法使用的东西。

或许,如同部分评论所言,此举乃是为某些语言的特性埋下伏笔。然而,此举却为 C# 带来了麻烦。我用上一篇文章里所说的方法创建了一个不继承自 System.ObjectNoInherit 类,置于 NoInherit.dll 中,然后用 Visual Studio 2005 新建一个项目,引用 NoInherit.dll,并在 Main 里写下这些代码:

 1不从 System.Object 继承之后Type t = typeof(NoInherit);
 2不从 System.Object 继承之后Console.WriteLine(t.BaseType == null);
 3不从 System.Object 继承之后
 4不从 System.Object 继承之后NoInherit ni = new NoInherit("NoInherit");
 5不从 System.Object 继承之后object o = ni as object;
 6不从 System.Object 继承之后if (o != null)
 7}

你猜上面代码的运行结果是什么?正常来说,运行结果应该只有一个 true,即第二行的输出,但事实上,第八行居然正确输出“NoInherit”,而第九行则抛出 AccessViolationException。按道理,第九行的异常是意料中事,但第二行和第五行的结果就很矛盾了。第二行输出 true 表明了 NoInherit 类的确没有继承自 System.Object,但第五行却转换成功,否则 o 应该是 null 的。

当一个系统复杂到一定程度,一个看似没问题的改动可能会导致一些看似不相关的问题。当你拿到一个库时,你是假定里面的所有类都继承自 System.Object,还是去验证一下呢?

相关文章:

  • 2022-02-03
  • 2022-01-01
  • 2021-10-25
  • 2021-08-09
  • 2021-12-01
  • 2021-07-07
  • 2021-06-24
  • 2022-02-26
猜你喜欢
  • 2021-08-11
  • 2022-12-23
  • 2021-11-05
  • 2021-04-08
  • 2021-07-30
  • 2021-10-05
相关资源
相似解决方案