以下将导致==运算符重载方法的无限递归
Foo foo1 = null;
Foo foo2 = new Foo();
Assert.IsFalse(foo1 == foo2);
public static bool operator ==(Foo foo1, Foo foo2) {
if (foo1 == null) return foo2 == null;
return foo1.Equals(foo2);
}
我如何检查空值？
我最近遇到过这种情况,到目前为止,我一直在愉快地重写等于运算符(==)和/或Equals方法,以查看两个引用类型是否实际包含相同的数据(即两个看起来相同的不同实例).
我一直在使用它,因为我已经进行了更多的自动化测试(比较参考/预期数据与返回的数据).
在查看MSDN中的一些编码标准指南时,我遇到了一篇建议反对它的文章.现在我理解为什么文章说这个(因为它们不是同一个实例)但它没有回答这个问题:
非常感谢^ _ ^
看起来我错误地阅读了一些文档(这是漫长的一天)并且压倒Equals可能是要走的路.
如果要实现引用类型,则应考虑在引用类型上覆盖Equals方法(如果类型看起来像基本类型,如Point,String,BigNumber等).大多数引用类型不应重载等于运算符,即使它们重写等于.但是,如果要实现旨在具有值语义的引用类型(例如复数类型),则应覆盖相等运算符.
使用该object.ReferenceEquals方法使用时会有额外的开销((object)obj1 == (object)obj2)吗？
在第一种情况下,将涉及静态方法调用,并且在两种情况下都涉及到对象的某种形式的转换.
即使编译器平衡了那些方法,那么不等式呢？
(object)obj != null
相比于...
!object.ReferenceEquals(obj,null)
我想在某些时候,会在!=运算符内或者应用于ReferenceEquals方法的结果时发生逻辑否定.你怎么看？
还有可读性问题需要考虑.在检查相等性时,ReferenceEquals似乎更清晰,但是对于不平等,可能会错过!前面的内容object.ReferenceEquals,而!=第一个变体中很难忽略.
我经常在源代码中看到if(object.ReferenceEquals(myObject,null))的用法,用于检查myObject是否为null而不是我熟悉的if(myObject == null).
是否有任何特殊原因(如速度,可读性等)使用第一种方式而不是第二种方式？你用哪一个？
先感谢您.
我想写一些条件检查,而不必使用try/catch,我想避免获得Index Out of Range错误的可能性
if (array.Element[0].Object.Length > 0 || array.Element[1].Object.Length > 0) //making sure there's at least one Object array that has values
{
if (array.Element[0].Object[0].Item.Length != 0 || array.Element[1].Object[0].Item.Length != 0) //this is where I check that at least one of the Items (strings) is not empty
{
// execute code here
}
}
所以我面临的问题是,在第二次检查时,我需要查看是否有一个非空的项目.但是,如果我没有Element[1],我会得到Index Out of Range异常.问题是可能有2个元素,其中一个(或两个)可能有空的Object数组.仅当其中一个Item字符串不为空时,才必须执行代码.
希望,我解释得很好.我如何避免在任何情况下避免异常？