しかし、演算子のオーバーロードシナリオ以外では、ReferenceEquals vs ==に利点はありますか？
いいえ-明示的に使用することの唯一の利点（そして私はそれはあまり利点ではないと主張します）Object.ReferenceEqualsは、オーバーロードされた演算子equalsを決して使用しないことです。オーバーロードされていない場合、==演算子は、すべての「文字列以外の参照型」に対して「2つのオペランドが同じオブジェクトを参照している場合にtrueを返す」と定義されています。そのため、同等のもの（オーバーロードされていない場合）。
私は個人的にも2番目の構文を使用することを好み、nullチェックの方が保守しやすいと感じています。私はまた、オーバーロードされたものはoperator==に対して適切なチェックを提供する必要があると主張しますnull、そしてそれが何らかの理由でそうでなかった場合（それは奇妙でしょう）、あなたが望むようになるその決定の背後にある特定の論理的根拠があるでしょうではなく、オーバーロードを使用しますReferenceEquals。
まあ、もし誰かが == や != 演算子を上書きするなら、彼らは彼らがやりたいことを何でもすることができます. return true;またはのような本当に意味のあることを行うことさえできreturn false;ます。さらに、オーバーロードされたオペレーターがある場合、パフォーマンスが低下する可能性が十分にありますReferenceEquals(保証されていませんが、問題になるほどではないかもしれませんが、それでも)。
そうは言っても、オーバーロードされた演算子の賢明な実装では、これが問題になることはほとんどありません。その型またはその特定のインスタンスで演算子をReferenceEquals使用しないというやむを得ない理由がない限り、私は個人的には使用しません。==
null チェックに関しては、この 2 つは常に同じ結果を返す必要があります。ReferenceEquals または == 演算子が使用されたかどうかに関係なく、null 以外の参照が null に等しい場合 (Null オブジェクト パターンを使用している場合でも)、それは非常に悪いことです。したがって、そのシナリオでは ==/!= を使用します。
== 演算子がオーバーロードされている場合は、ReferenceEquals を使用した方がわずかに高速になる可能性があります。オーバーロードされた == が最初に行うべきことは、2 つの変数が同じオブジェクトを指しているかどうかを確認することです。そのため、オーバーロードされた演算子の場合、コール スタックに余分なフレームが作成されます。ReferenceEquals を使用すると、それが実行される唯一のチェックであることも保証されます。
私は通常、他のほとんどすべてのシナリオで ==/!= も使用します。全体的な考え方は、オペレーターが「平等」を定義するということです。これは常に参照的であるとは限りません (実際、ほとんどの複合オブジェクトは構造的に同等かどうかを比較する必要があります。メンバーが等しい場合、それらは同等です)。理論的には、オブジェクトは、等価性、相対的な順序などについて、自分自身を別のオブジェクトと比較する最善の方法を知っています。オブジェクトが他のものと等しいかどうかをオブジェクトに伝えさせます。
VB.NETタグは、特に言及されていないため、おそらくこの質問に含めるべきではありませんが、完全を期すために、Isと同等Object.ReferenceEqualsであるため、その呼び出しの代わりに常に使用できます。
他の回答で説明されているように、2 つの呼び出しの意味は少し異なります。
のセマンティックを使用したいReferenceEqualsが、単純化された構文を使用したい場合は、参照型に次を使用することもできます。
if (myObject is object)