2013-02-15 54 views
2

什麼會被你的理由不寫我爲什麼不寫list.Count.Equals(0)

list.Count.Equals(0) 

,當你可能會寫

list.Count == 0 

是否有技術/語義原因是什麼?

+3

第二種情況更具可讀性,不是嗎? – abatishchev 2013-02-15 08:01:28

+2

這取決於'list'實際是什麼('Equals'可能有不同於'operator =='的覆蓋,但它只是愚蠢的)。一般來說,'list.Any()'是檢查空列表的首選方法。 – 2013-02-15 08:02:11

+1

@ArtemKoshelev:這取決於'list.Count'實際是什麼。 – 2013-02-15 08:13:08

回答

4

我認爲這個具體案例的兩個陳述之間沒有區別。由於您正在檢查值爲int的等式; ==運營商和Equals做了完全相同的操作。

但是對於其他一些情況,例如對於以下情況,它們可能會返回不同的值;

Double.NaN == Double.NaN // is false 
Double.NaN.Equals(Double.NaN) // is true 

通常,對於值類型,您可以使用==;但如果它是一個參考類型,最好去Equals

對於int樣本的反彙編顯示如下;生成的彙編代碼會有所不同,所以預計性能會有所不同;

  int a = 10; 
00000080 mov   dword ptr [ebp-40h],0Ah 
       int b = 9; 
00000087 mov   dword ptr [ebp-44h],9 

       bool x = a == b; 
0000008e mov   eax,dword ptr [ebp-40h] 
00000091 cmp   eax,dword ptr [ebp-44h] 
00000094 sete  al 
00000097 movzx  eax,al 
0000009a mov   dword ptr [ebp-48h],eax 
       bool y = a.Equals(b); 
0000009d lea   ecx,[ebp-40h] 
000000a0 mov   edx,dword ptr [ebp-44h] 
000000a3 call  6B8803C0 
000000a8 mov   dword ptr [ebp-60h],eax 
000000ab movzx  eax,byte ptr [ebp-60h] 
000000af mov   dword ptr [ebp-4Ch],eax 
2

的兩個主要原因是

  1. list.Count == 0是更容易閱讀(最重要的)

  2. list.Count.Equals(0)是較慢

+5

你爲什麼覺得它慢?我認爲int的運算符重載使用Equals覆蓋。 – abatishchev 2013-02-15 08:02:14

+0

對我來說,原因是等於參考類型不是值類型,如整數。 – Elisabeth 2013-02-15 08:04:08

+1

int上的等於不會被裝箱。 – Alex 2013-02-15 08:07:14

2

list.Count == 0具有更好的可讀性和更短的imo。如果性能可以忽略不計,那麼總是要用更可讀的方式去做,並以最清晰的方式展示意圖。

至於技術上的原因:如果你比較兩個生成的IL序列。

IL_0029: callvirt instance int32 class [mscorlib]System.Collections.Generic.List`1<string>::get_Count() 
    IL_002e: stloc.s CS$0$0001 
    IL_0030: ldloca.s CS$0$0001 
    IL_0032: ldc.i4.0 
    IL_0033: call  instance bool [mscorlib]System.Int32::Equals(int32) 
    // Equals(obj int) internally uses the method this == obj; 

IL_007f: callvirt instance int32 class [mscorlib]System.Collections.Generic.List`1<string>::get_Count() 
    IL_0084: ldc.i4.0 
    IL_0085: ceq 

人們可以爭辯說,==操作符是速度更快,因爲它使用較少的指令,沒有人真正知道它如何被優化,雖然。

運行JIT熱身和其中首先調用的不同序列的快速基準,您會注意到(至少在我的機器上)迭代超過100000000個元素==的速度快了大約25 ms。