沒什麼不好理解的吧？圖中的示例是一個數組，分別用下標和指標的方式來訪問，僅就這一種情形而言，是完全可能的。

早期的編譯器的程式碼最佳化功能不夠強，這兩種方式最終生成的二進位制程式碼是不同的，自然就有效能上的差異。

而現在的編譯器完全能識別出，這兩種方式其實是同一種模式：以順序方式訪問一段連續的記憶體空間。這樣最終生成的二進位制程式碼，甚至可以是完全相同的，自然也就不存在效能差異了。

既然編譯生成的程式碼差別不打，那確實效率方面差別也不大了。說到底還是因為我們深入研究核心技術的力量還是很薄弱。華為的gt技術應該就是彙編層面的最佳化吧。對於大部分人來說生成的差別不大就夠了，不過正是這一點點的少積累成新技術的

就應用來說，在基礎的賦值判斷迴圈上的差別無所謂，但是一旦在這些基礎上能最佳化，整體提升那是相當大的。

不要曲解作者的意思，作者所說的只是陣列使用的效率比指標低，但是現代有些處理器有專門的機器指令彌補這個差距。有時間可以自己看看陣列編譯的彙編程式碼和指標的。在你看來這都是指標，但是編譯的時候是不一樣的。但是為了程式碼的可讀性，我們一般建議採用陣列方式來用，畢竟這點效率不值得浪費程式碼可讀性。

樓上的人有些直接扯到用不用指標的問題去了…最近剛好看到這部分，我已經使用C5年有多，每次看大牛寫的書，每次都有新的理解和感悟，C很底層，要結合計算機系統原理去領悟。特別是指標

也許時代變了吧。

我還是認為指標的效率高。文中說的現代的編譯器指標和陣列的效率相差不大，這個說法比較模糊。1. 畢竟二者還是有差距，差距有多大沒有明說；2. “現代的編譯器”是指什麼時候的編譯器？而且不能保證所有的編譯器都能縮小二者的差距（如果這種技術確實存在）。

因此，建議還是按傳統的C語言程式設計宗旨，按指標的效率高來程式設計。

就看到了一張圖，沒看到怎麼解釋沒什麼高效這句話。就拿看到的這張圖說下吧，for迴圈裡寫的p++,這種做法個人覺得和陣列迴圈差不多，但改成++p在資料量大的時候就能看出效能差距了

C語言指標依然是一個不可被替代的事物，也許指標和陣列對於當代的編譯器來說處理效率都差不多，但是多學習一點指標的知識總歸是有好處的，對鍛鍊自己的抽象思維能力有好處的。

而且在一些場合中，比如連結串列處理中，指標是最好用的。

這個是目前最佳化原理普遍公認的事實，指標說到底沒有型別，編譯器很難理解，也就無法最佳化。

現在CPU的快取比主記憶體快的多，用指標直接訪問記憶體，不是好主意。

以前用指標主要是，函式呼叫和返回時只要複製指標本身。而不是複製指標指向的內容。現在編譯器有很多辦法避免記憶體複製。

最近在學c++，正看的一本c++的書，也是這個意思。但據我的理解，這只是針對編譯時能確定資料大小的陣列這種情況，或者類似的情況。但是很多資料的大小數量等是需要在執行時才確定的，那你就要動態的申請記憶體空間了，怎麼表示和使用這塊記憶體區域呢，指標就派上用場了。當然你也可以在編譯時預先定義一個很大很大的陣列，好能放的下不確定的可能相當多的資料，但這樣的話顯然不如動態申請記憶體更節省空間，更有效率。所以指標還是一定要學的，而且還要學好的，千萬不要輕視。

指標的處理最好封裝為各種方法儘量過程可以切分為多個方法，這樣效率隨差但是排除bug會容易很多，這都是血和淚的經驗啊。除非是介面或者最佳化的問題還是少用指標，畢竟穩定是第一位的

指標被妖魔化了，指標實質就是記憶體地址，要使用記憶體必須要先知道記憶體地址，無論你如何躲避最終都要用到，只是繞個彎路，或者完全交給作業系統來處理，總之無論交給誰處理，結果都是必須處理，這是繞不過去的。要用好指標那就要深入全面的瞭解指標，最好從彙編層面來了解，畢竟指標的效率高，這是不爭的事實。