詳細介紹C/C++數組名與指標區別

本文轉自chinaitlab的博文

指標是C/C++語言的特色，而數組名與指標有太多的相似，甚至很多時候，數組名可以作為指標使用。於是乎，很多程式設計者就被搞糊塗了。而許多的大學老師，他們在C語言的教學過程中也錯誤得給學生講解："數組名就是指標"。很幸運，我的大學老師就是其中之一。時至今日，我日複一日地進行著C/C++項目的開發，而身邊還一直充滿這樣的程式員，他們保留著"數組名就是指標"的誤解。

　　想必這種誤解的根源在於國內某著名的C程式設計教程。如果這篇文章能夠糾正許多中國程式員對數組名和指標的誤解，筆者就不甚欣慰了。藉此文，筆者站在無數對知識如饑似渴的中國程式員之中，深深寄希望於國內的電腦圖書編寫者們，能以"深入探索"的思維方式和精益求精的認真態度來對待圖書編寫工作，但願市面上多一些融入作者思考結晶的心血之作！
　　魔幻數組名
　　請看程式（本文程式在WIN32平台下編譯）：

　　1、數組名不是指標
　　我們先來推翻"數組名就是指標"的說法，用反證法。
　　證明　數組名不是指標
　　假設：數組名是指標；
　　則：pStr和str都是指標；
　　因為：在WIN32平台下，指標長度為4；
　　所以：第6行和第7行的輸出都應該為4；
　　實際情況是：第6行輸出10，第7行輸出4；
　　所以：假設不成立，數組名不是指標
　　2、數組名神似指標

　　上面我們已經證明了數組名的確不是指標，但是我們再看看程式的第5行。該行程式將數組名直接賦值給指標，這顯得數組名又的確是個指標！

我們還可以發現數組名顯得像指標的例子：

　　標準C庫函數strcpy的函數原形中能接納的兩個參數都為char型指標，而我們在調用中傳給它的卻是兩個數組名！函數輸出：

　　數組名再一次顯得像指標！
　　既然數組名不是指標，而為什麼到處都把數組名當指標用？於是乎，許多程式員得出這樣的結論：數組名（主）是（謂）不是指標的指標（賓）。
　　整個一魔鬼。
　　揭密數組名
　　現在到揭露數組名本質的時候了，先給出三個結論：
　　(1)數組名的內涵在於其指代實體是一種資料結構，這種資料結構就是數組；
　　(2)數組名的外延在於其可以轉換為指向其指代實體的指標，而且是一個指標常量；
　　(3)指向數組的指標則是另外一種變數類型（在WIN32平台下，長度為4），僅僅意味著數組的存放地址！
　　1、數組名指代一種資料結構：數組
　　現在可以解釋為什麼第1個程式第6行的輸出為10的問題，根據結論1，數組名str的內涵為一種資料結構，即一個長度為10的char型數組，所以sizeof(str)的結果為這個資料結構佔據的記憶體大小：10位元組。
　　再看：

　　第2行的輸出結果為40（整型數組佔據的記憶體空間大小）。
　　如果C/C++程式可以這樣寫：

　　我們就都明白了，intArray定義為int[10]這種資料結構的一個執行個體，可惜啊，C/C++目前並不支援這種定義方式。
　　2、數組名可作為指標常量
　　根據結論2，數組名可以轉換為指向其指代實體的指標，所以程式1中的第5行數組名直接賦值給指標，程式2第7行直接將數組名作為指標形參都可成立。
　　下面的程式成立嗎？
 
　　讀者可以編譯之，發現編譯出錯。原因在於，雖然數組名可以轉換為指向其指代實體的指標，但是它只能被看作一個指標常量，不能被修改。
　　而指標，不管是指向結構體、數組還是基礎資料型別 (Elementary Data Type)的指標，都不包含未經處理資料結構的內涵，在WIN32平台下，sizeof操作的結果都是4。
　　順便糾正一下許多程式員的另一個誤解。許多程式員以為sizeof是一個函數，而實際上，它是一個操作符，不過其使用方式看起來的確太像一個函數了。語句sizeof(int)就可以說明sizeof的確不是一個函數，因為函數接納形參（一個變數），世界上沒有一個C/C++函數接納一個資料類型（如int）為"形參"。

3、資料名可能失去其資料結構內涵
　　到這裡似乎數組名魔幻問題已經宣告圓滿解決，但是平靜的湖面上卻再次掀起波浪。請看下面一段程式：

　　程式的輸出結果為4。不可能吧？
　　一個可怕的數字，前面已經提到其為指標的長度!
　　結論1指出，資料名內涵為數組這種資料結構，在arrayTest函數體內，str是數組名，那為什麼sizeof的結果卻是指標的長度？這是因為：
　　(1)數組名作為函數形參時，在函數體內，其失去了本身的內涵，僅僅只是一個指標；
　　(2)很遺憾，在失去其內涵的同時，它還失去了其常量特性，可以作自增、自減等操作，可以被修改。
　　所以，資料名作為函數形參時，其全面淪落為一個普通指標！它的貴族身份被剝奪，成了一個地地道道的只擁有4個位元組的平民。
　　以上就是結論4。
　　結束語
　　最後，筆者再次表達深深的希望，願我和我的同道中人能夠真正以謹慎的研究態度來認真思考開發中的問題，這樣才能在我們中間產生大師級的程式員，頂級的開發書籍。每次拿著美國鬼子的開發書籍，我們不免發出這樣的感慨：我們落後太遠了。