深入探索 C/C++ 數組與指標的奧秘之二：數組名是一個指標常量嗎？

深入探索 C/C++ 數組與指標的奧秘之二：數組名是一個指標常量嗎？

          數組名是一個指標常量這種觀點來源於數組名在運算式計算中與指標的結果等效性。例如下面的代碼：

int a[10], *p = a, *q;</p><p>q = a + 1;</p><p>q = p + 1; 
          在效果上看，a + 1 與 p + 1 是相同的，這很容易給人一種 a 就是 p 的假象，但，這僅僅是假象。鑒於指標常量包含了指標和常量兩類概念，我們可以把這個問題分開兩部分進行討論。
          一、數組名是指標嗎？
          在《C 與指標》一書中，作者用一個著名的例子闡述了數組名與指標的不同。在一個檔案中定義：int a[10];然後在另一個檔案中聲明：extern int *a; 筆者不在這裡重複其中的原理，書中的作者試圖從底層操作上闡述數組名與指標的不同點，但筆者認為這個例子存在一些不足，a 在運算式中會轉換為一個非對象的符號地址，而指標 a 卻是一個對象，用一個非對象去跟一個對象比較，有“偷跑”的嫌疑，這個例子只是說明了數組名的非對象性質，只能證明對象與非對象實體在底層操作上的不同，事實上，如上一章所述，指標也有非對象形態。筆者認為，無須從底層的角度上花費那麼多唇舌，僅僅從字面上的語義就可以推翻數組名是一個指標的觀點。
          首先，在 C/C++ 中，數群組類型跟指標類型是兩種不同的衍生類別型，數組名跟指標是兩種不同類型的實體，把數群組類型的實體說成“是”另一個類型的實體，本身就是荒謬的；
          其次，a + 1 在效果上之所以等同於 p + 1，是因為 a 進行了數組到指標的隱式轉換，這是一個轉換的過程，是 converted to 而不是 is a 的過程。如果是兩個相同的事物，又怎會有轉換的過程呢？當把 a 放在 a + 1 運算式中時，a 已經從一個數組名轉換為一個指標，a 是作為指標而不是數組名參與運算的；
          第三，a + 1 與 p + 1 是等效關係，不是等價關係。等價是相同事物的不同表現形式，而等效是不同事物的相同效果。把數組名說成是指標實際上把等效關係誤解為等價關係。
          因此，數組名不是指標，永遠也不是，但在一定條件下，數組名可以轉換為指標。
          二、數組名是一個常量嗎？
          看見這句話有人會覺得奇怪，數組定義之後就不能改變了，數組名不就是個常量嗎？在運算式中，數組名的確可以轉換為一個不變的符號地址，但在 C 中，不變的實體不一定是常量！而且，C/C++ 有常量與常量運算式之分，常量與常量運算式是兩種不同的實體，但常量運算式可以作為常量使用。C/C++ 中的常量雖然有所不同，但都不包括數組或數組名，而且數組名也不一定是常量運算式。
          請在 C90 的編譯器中編譯如下代碼，注意不能是 C99 和 C++ 的，因為 C99 和 C++ 不再規定數組的初始化器必須是常量運算式，會看不到效果：

int main( void )</p><p>{</p><p> static int a[10], b[10];</p><p> int c[10], d[10];</p><p> int* e[] = { a, b }; /* A */</p><p> int* f[] = { c, d }; /* B */</p><p> return 0;</p><p>} 
          B 為什麼不能通過編譯？是由於自動數組名並不是常量運算式。在 C 中，常量運算式必須是編譯期的，只在運行期不變的實體不是常量運算式，請看標準的摘錄：
          6.6 Constant expressions
          A constant expression can be evaluated during translation rather than runtime, and accordingly may be used in any place that a constant may be.
          c 和 d 是自動數組，首地址在編譯期是不可知的，因為這樣的對象在編譯期還不存在；a 和 b 是靜態數組，靜態對象從程式開始時就已存在，因此 a 和 b 的首地址在編譯期是已知的，它們都屬於常量運算式中的地址常量運算式。
          所以，C/C++ 中的數組名，都不是常量。C 中的數組名，是否常量運算式要視其儲存連續性而定，全域數組、靜態數組名都是常量運算式，而自動數組名不是。在 C++ 中，由於不再規定常量運算式必須是編譯期的，因此 C++ 的數組名都是常量運算式。
原文連結：http://blog.csdn.net/supermegaboy/archive/2009/11/23/4855018.aspx。