即使没有空检查，使用“as”而不是强制转换是否有意义？ [关闭]

Question

在开发博客、在线代码示例和（最近）甚至是一本书中，我总是对这样的代码磕磕绊绊：

var y = x as T;
y.SomeMethod();

或者，更糟糕的是：

(x as T).SomeMethod();

这对我来说没有意义。如果您确定x 的类型为T，则应使用直接转换：(T)x。如果不确定，可以使用as，但需要在执行某些操作之前检查null。以上代码所做的就是将（有用的）InvalidCastException 变成（无用的）NullReferenceException。

只有我认为这是对as 关键字的公然滥用吗？还是我错过了一些明显的东西，而上面的模式实际上是有道理的？

Answer 1

您的理解是正确的。这听起来像是试图对我进行微优化。当您确定类型时，您应该使用正常转换。除了产生更合理的异常之外，它也很快失败。如果您对类型的假设有误，您的程序将立即失败，您将能够立即看到失败的原因，而不是等待 NullReferenceException 或 ArgumentNullException 甚至在某个时间出现逻辑错误未来。通常，as 表达式后面没有 null 检查某处是代码异味。

另一方面，如果您不确定转换并预计它会失败，您应该使用as 而不是用try-catch 块包裹的普通转换。此外，建议使用as，而不是类型检查，然后进行强制转换。而不是：

if (x is SomeType)
   ((SomeType)x).SomeMethod();

为is关键字生成isinst instruction，为强制转换生成castclass instruction（有效地执行了两次强制转换），您应该使用：

var v = x as SomeType;
if (v != null)
    v.SomeMethod();

这只会生成isinst 指令。前一种方法在多线程应用程序中存在潜在缺陷，因为竞争条件可能会导致变量在is 检查成功后更改其类型并在强制转换行失败。后一种方法不容易出现这个错误。

---

_{不推荐在生产代码中使用以下解决方案。如果你真的讨厌 C# 中的这种基本结构，你可以考虑改用 VB 或其他语言。}

如果一个人非常讨厌强制转换语法，他/她可以编写一个扩展方法来模仿强制转换：

public static T To<T>(this object o) { // Name it as you like: As, Cast, To, ...
    return (T)o;
}

并使用简洁的[?] 语法：

obj.To<SomeType>().SomeMethod()

Answer 2

恕我直言，as 与null 检查结合使用才有意义：

var y = x as T;
if (y != null)
    y.SomeMethod();

Answer 3

使用“as”不会应用用户定义的转换，而演员会在适当的时候使用它们。在某些情况下，这可能是一个重要的区别。

Answer 4

我在这里写了一点：

http://blogs.msdn.com/ericlippert/archive/2009/10/08/what-s-the-difference-between-as-and-cast-operators.aspx

我明白你的意思。我同意它的主旨：演员表操作员传达“我确信这个对象可以转换为那种类型，如果我错了，我愿意冒异常的风险”，而“as”操作员传达“我不确定这个对象是否可以转换为那种类型；如果我错了，给我一个空值”。

但是，有一个细微的差别。 (x as T).Whatever() 传达“我不仅知道 x 可以转换为 T，而且，这样做只涉及引用或拆箱转换，而且 x 不为空”。这确实传达了与 ((T)x).Whatever() 不同的信息，也许这就是代码作者的意图。

Answer 5

我经常看到对this misleading article 的引用作为“as”比强制转换更快的证据。

本文更明显的误导性方面之一是图形，它没有表明正在测量的内容：我怀疑它正在测量 失败 演员表（其中“as”显然比 no 要快得多抛出异常）。

如果您花时间进行测量，那么您会发现，如您所料，当转换成功时，转换比“as”快。

我怀疑这可能是“cargo cult”使用 as 关键字而不是 cast 的原因之一。

Answer 6

直接转换需要一对括号而不是as 关键字。因此，即使您 100 % 确定类型是什么，它也可以减少视觉混乱。

同意例外的事情，不过。但至少对我来说，as 的大多数使用归结为事后检查 null，我发现这比捕获异常更好。

Answer 7

当我使用“as”时，99% 的情况是我不确定实际的对象类型是什么

var x = obj as T;
if(x != null){
 //x was type T!
}

我不想捕获显式转换异常，也不想使用“is”进行两次转换：

//I don't like this
if(obj is T){
  var x = (T)obj; 
}

Answer 8

只是因为人们喜欢它的外观，它的可读性很强。

让我们面对现实吧：类 C 语言中的强制转换/转换运算符非常糟糕，可读性很差。如果 C# 采用以下 Javascript 语法，我会更好：

object o = 1;
int i = int(o);

或者定义一个to 操作符，相当于as：

object o = 1;
int i = o to int;

Answer 9

人们非常喜欢as，因为这让他们感到不受例外的影响……就像盒子上的保证一样。一个人在盒子上放了一个花哨的保证，因为他希望你在里面感到温暖和温暖。你想你晚上把那个小盒子放在枕头下，保证仙女可能会下来留下四分之一，我说得对吗泰德？

回到主题...当使用直接强制转换时，可能出现无效强制转换异常。所以人们将as 用作满足他们所有选角需求的一揽子解决方案，因为as（本身）永远不会抛出异常。但有趣的是，在您给(x as T).SomeMethod(); 的示例中，您正在用无效转换异常换取空引用异常。当您看到异常时，这会混淆真正的问题。

我一般不会过多使用as。我更喜欢 is 测试，因为对我来说，它看起来更具可读性并且比尝试强制转换和检查 null 更有意义。

Answer 10

这必须是我的top peeves 之一。

Stroustrup 的 D&E 和/或我现在找不到的一些博客文章讨论了 to 运算符的概念，该运算符将解决 https://stackoverflow.com/users/73070/johannes-rossel 提出的观点（即，与 as 相同的语法，但具有 DirectCast 语义)。

这没有得到实现的原因是因为演员应该会导致痛苦和丑陋，所以你会被推开使用它。

遗憾的是，“聪明”的程序员（通常是书籍作者 (Juval Lowy IIRC)）通过以这种方式滥用 as 来绕过这个问题（C++ 不提供 as，可能是因为这个原因）。

即使是 VB，在统一语法方面也更加一致，迫使您选择 TryCast 或 DirectCast 并下定决心！

Answer 11

我相信 as 关键字可以被认为是外观更优雅的版本 dynamic_cast 来自 C++。

Answer 12

它可能更受欢迎，没有技术原因，只是因为它更容易阅读和更直观。 （并不是说只是尝试回答问题会更好）

Answer 13

使用“as”的一个原因：

T t = obj as T;
 //some other thread changes obj to another type...
if (t != null) action(t); //still works

而不是（错误代码）：

if (obj is T)
{
     //bang, some other thread changes obj to another type...
     action((T)obj); //InvalidCastException
}