Effective C# 條款2

 圖1編譯時間常量和運行時常量區別

 

　　編譯時間常量比運行時常量稍微快一點，但卻缺乏靈活性，但如果程式“慢”能確保正確運行，“快”有可能導致出錯，那麼我相信大家考慮到“常量之間何必在乎那一點點誤差呢”當然穩定性首選的是運行時常量。

// 編譯時間常量聲明： 

public const int _Millennium = 2000; 



// 運行時常量聲明：

public static readonly int _ThisYear = 2011;

 

                         圖2 運行時和編譯時間常量的MSIL代碼

　　通過比較編譯時間常量和運行時常量的MSIL代碼發現，編譯常量在編譯後為變數提供常量值，而運行時常量並沒有提供常量值。

　　我們知道，運行時常量和編譯時間常量最重要的區別就在於運行時常量值的辨析發生在運行時，而編譯時間常量值的辨析發生編譯時間。換言之，使用運行時常量編譯後的 IL 代碼引用的是 readonly 變數，而非它的值；而使用編譯時間常量編譯後的 IL 代碼將直接引用它的值——就像我們直接在代碼中使用常量值一樣。即使我們使用的是數值常量並跨程式集引用，情況也是一樣：如果在程式集 A 中引用程式集 B 中的常量，那麼編譯後程式集 A 中出現的那個常量將被它的值所替換。這種差別對於代碼的維護性而言有著相當的影響。

現在讓我們看一下它們的區別：

    /// <summary>
/// 定義運行時常量和編譯時間常量
/// </summary>
    public class TestClass
    {
public const int isConstVar = 5;
public static readonly int inReadonlyVar = 1;
    }

    /// <summary>
/// 測試回合時和編譯時間常量區別
/// </summary>
    class Program
    {
static void Main(string[] args)
        {
for (int i = TestClass.TestClass.inReadonlyVar; i < TestClass.TestClass.isConstVar; i++)
            {
                Console.WriteLine("This is {0}", i);
            }
            Console.ReadKey();
        }
    }

      圖3輸出結果

圖4編譯常量和運行常量MSIL

 

 

　　通過上面我們可以發現編譯時間常量是通過hard code方式替換為一個值常量，而運行時常量是通過一個引用方式來，如果我們修改編譯時間常量值為10，而運行時常量值為3，修改如下：

    public class TestClass
    {
public const int isConstVar = 10;
public static readonly int inReadonlyVar = 3;
    }

　　

　　如果我們重新編譯TestClass，然而不重新編譯Program控制台應用程式，而且把重新編譯後的TestClass copy到控制台應用程式的bin中再次運行，大家可以猜猜看最後輸出的結果，我相信聰明的你肯定可以猜得到結果，沒錯結果如下：

    圖5輸出結果

 

 

　　分析原因在於C#編譯器在第一次編譯控制台應用程式集時，將其中的 isConstVar替換成了它對應的常量值5，而對於 inReadonlyVar來說，由於它被聲明為 readonly，所以它的辨析發生在運行時。因此，控制台應用程式集在沒有被重新編譯的情況下， 仍然可以使用新的 inReadonlyVar值。