即使没有空检查,使用“ as”代替强制转换是否有意义?[关闭]

即使没有空检查,使用“ as”代替强制转换是否有意义?[关闭],第1张

即使没有空检查,使用“ as”代替强制转换是否有意义?[关闭]

您的理解是真的。这听起来像是尝试对我进行微优化。确定类型时,应使用常规演员表。除了生成更明智的异常之外,它还会快速失败。如果你错了你对类型的假设,你的程序将立即失败,你就可以看到失败立即,而不是等待的原因一个

NullReferenceException
或者
ArgumentNullException
甚至是一个逻辑上的错误在未来的某个时候。通常,
as
没有在
null
某处进行检查的表达式就是代码味道。

另一方面,如果不确定转换是否正确,并期望转换失败,则应使用

as
包裹有
try-catch
块的普通转换来代替。此外,
as
建议在类型检查后再进行强制类型转换后再使用。代替:

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

其产生的

isinst
指令为
is
关键字,和
castclass
指令的投(有效执行转换两次),你应该使用:

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()


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zaji/5567456.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-12-14
下一篇 2022-12-14

发表评论

登录后才能评论

评论列表(0条)

保存