我们来谈谈面向指针编程的那些事
面向?qū)ο缶幊?#xff0c;面向設(shè)計模式編 程(亦即設(shè)計模式),面向接口編程,面向模板編程(亦即泛型編程),面向函數(shù)編程(亦即函數(shù)式編程),面向多核時代的并行編程,面向大數(shù)據(jù)的機器學習編 程……這么多年,大家要面向的東西已經(jīng)夠多了,然而我看到的現(xiàn)象是,很多編程語言讓大家面向 xxx 的同時在竭力回避指針。我可不想面向這么多東西,所以我只好加入指針的黑暗勢力。我要不自量力的來寫一篇《面向指針編程》作為投名狀,借以表示我與軟件世 界的光明勢力的徹底決裂。
這個世界上,提供指針的編程語言很少,這樣的語言有匯編語言、C/C++ 以及 Pascal 等。Pascal 我沒學過。匯編語言過于黑暗,我現(xiàn)在功力還不足以駕馭它。C++,我覺得它簡直是黑暗勢力中的敗類——它試圖掙脫指針,走向光明,結(jié)果卻出了一堆幺蛾子。 所以我還是俗套的選 C 語言來闡述指針的黑暗力量。
閱讀本文之前,請讀三遍 Unix 無名師說的話:當尊者 Ritchie 發(fā)明 C 時,他將程序員放到緩沖溢出、堆損壞和爛指針 bug 的地獄中懲罰。然后自我安慰一下,如果地獄未能使我屈服,那么我會比地獄更黑暗更強大。
指針是什么?
內(nèi)存是以字節(jié)為單位的一個很大但是又經(jīng)常不夠用的空間。指針是內(nèi)存中 x 個連續(xù)的字節(jié)中存儲的數(shù)據(jù)——在 32 位的機器上,x 的值為 4;在 64 位機器上,x 值為 8。為了敘述的簡便,本文只在 64 位的機器上談?wù)撝羔槨?/p>
指針是一種數(shù)據(jù),這沒什么稀奇的。從機器的角度來看,程序的一切是存放在數(shù)組中的數(shù)據(jù)。只有那些自作多情的程序猿才會像亞里士多德一樣自作多情的認 為程序是由對象 + 方法或者許多函數(shù)復(fù)合而成的。事實上,從最遠離機器的 Lisp 語言的角度來看,程序的一切也都是數(shù)據(jù),存放在表中的數(shù)據(jù)。如果忽視程序本身就是數(shù)據(jù)這個客觀事實,程序猿們很容易就走上了形而上學的道路,然后他們會度 過漫長的、罪惡的、痛苦的中世紀,膜拜著一個又一個神棍,當然期間也出現(xiàn)了幾位圣·奧古斯丁。
那么,指針中存儲著什么數(shù)據(jù)?內(nèi)存地址。
內(nèi)存是以字節(jié)為單位的空間,其中每個字節(jié)都伴隨著一個地址,這個地址機器賦予的,并不是我們的程序編制的。你可以將整個內(nèi)存空間想象成一棟大樓,將字節(jié)想象為大樓中每個房間,將每個字節(jié)的地址想象為房間的門牌號,于是指針中存儲的數(shù)據(jù)就類似于門牌號。
如果你從未學過 C 語言,讀到此處可能會問,我們?yōu)槭裁匆趦?nèi)存中存儲內(nèi)存地址?不知你是否住過賓館。在正規(guī)的賓館里,每個房間的門后都會貼著逃生路線圖,圖中『存儲』了該 賓館與你的房間同一樓層內(nèi)的全部房間的門牌號以及它們的布局。如果你住酒店時從來也不看逃生路線圖,那么從現(xiàn)在開始,入住酒店后第一件事就是認真的看一下 它,關(guān)鍵時刻它能救你一命。在內(nèi)存中存儲內(nèi)存地址,雖然不是救你性命的,但是可以藉此構(gòu)造與賓館逃生路線圖相似的抽象事物——內(nèi)存數(shù)據(jù)的抽象與復(fù)合。
內(nèi)存空間的有名與無名
現(xiàn)在來看兩行 C 代碼:
foo?是什么?foo?表示一個內(nèi)存地址。foo?前面的?int?是數(shù)據(jù)類型修飾,它表示?foo?是內(nèi)存中 4 個連續(xù)字節(jié)的首字節(jié)地址( 64 位機器上,int?類型的數(shù)據(jù)長度為 4 個字節(jié))。C 編譯器總是會根據(jù)某個內(nèi)存地址相應(yīng)的類型來確定以該內(nèi)存地址起始的一段連續(xù)字節(jié)中所存儲的數(shù)據(jù)的邏輯意義。因此,當我們用?int?類型來修飾?foo,編譯器就會認為以?foo?開始的連續(xù) 4 個字節(jié)中存儲的數(shù)據(jù)是一個整型數(shù)據(jù)。在上述代碼中,這個整型數(shù)據(jù)是?10,我們通過賦值運算符?=?將這個整型數(shù)保存到內(nèi)存中以?foo?地址開始的連續(xù) 4 個字節(jié)中。
從此刻開始,要記住一個事實,那就是?C 語言中所有的變量名,本質(zhì)上都是內(nèi)存地址。之所以不直接使用內(nèi)存地址,而是使用一些有意義的名字,這就類似于沒人愿意用你的身份證號來稱呼你,大家更愿意用你的姓名來稱呼你。
由于 C 語言認為數(shù)據(jù)的長度是由其類型確定的。例如,int?類型的數(shù)據(jù)長度是 4 個字節(jié),char?類型的數(shù)據(jù)長度是是 1 個字節(jié),用戶自定義的?struct?類型的數(shù)據(jù)長度則是根據(jù)實際情況而待定。在這種情況下,所有表示內(nèi)存地址的名字,它們實質(zhì)上表示的是內(nèi)存中各種類型數(shù)據(jù)存儲空間的起始地址——專業(yè)一點,就是基地址。凡是用名字來表示基地址的內(nèi)存空間,我們就將其稱為有名的內(nèi)存空間。
再來看?bar?是什么?bar?是內(nèi)存地址的名字,由于?bar?前面有個?*?號,這表示我們打算在以 bar 為基地址的連續(xù) 8 個字節(jié)中存儲一個內(nèi)存地址(別忘了,我們是在 64 位機器上,指針數(shù)據(jù)的長度是 8 個字節(jié))——foo?所表示的那個地址,亦即?&foo。在這里,?&?是取值符,它會對?foo?說,你甭給我耍花樣了,老實交代你的身份證號!在*?之前還有?int,這意味著在以 bar 為基地址的連續(xù) 8 個字節(jié)中存儲的那個內(nèi)存地址是某個用于存儲整型數(shù)據(jù)的內(nèi)存空間的基地址。
由于?bar?是某個內(nèi)存空間的基地址,而這個內(nèi)存空間中存儲的是一個內(nèi)存地址,所以?bar?就是所謂的指針。在這里,我們可以認為?bar?是對某塊以?foo?為基地址的內(nèi)存空間的『引用』,也就是在一個房間號為?bar?的房間里存儲了房間號foo。按照 C 語言教材里常用的說法,可將?int *bar = &foo?這件事描述為『指針?bar?指向了整型變量?foo』,然而事實上內(nèi)存里哪有什么針,哪有什么指向?一切都是內(nèi)存空間的引用。在上面的例子里,我們是用?foo?來直接引用某個內(nèi)存空間,然后又使用?bar?來間接引用某個內(nèi)存空間。
在上面的例子里,bar?引用的是一個有名的內(nèi)存空間。那么有沒有無名的內(nèi)存空間呢?看下面的代碼:
malloc(sizeof(int))?就是一個無名的內(nèi)存空間,因為它是一個表達式,而這個表達式描述的是一系列行 為,行為需要借助動詞來描述,而無法用名詞來描述。比如『我在寫文章』,這種行為無法只使用名詞來描述,必須借助動詞。任何會終止的行為都可表示為一系列 的狀態(tài)的變化,也就是說任何會終止的行為都會產(chǎn)生一個結(jié)果,而這個結(jié)果可以用名詞來描述。例如?malloc(sizeof(int))?這個行為就是可終止的,它的結(jié)果是它在內(nèi)存所開辟 4 個字節(jié)的空間的基地址,這個基地址是沒有名字的,所以它就是個無名的基地址,因此它對應(yīng)的內(nèi)存空間就是無名的內(nèi)存空間,但是如果我們想訪問這個空間,就必須為它取個名字,當我們用?bar?指針引用它的基地址時,它就變成有名的了。
C 語言的創(chuàng)始人—— Dennis Ritchie 與 Brian Kernighan 將帶名字的存儲空間稱為對象(Object)——并非『面向?qū)ο缶幊獭恢械膶ο?#xff0c;然后將指代這個對象的表達式稱為左值(lvalue)。也就是說,在 C 語言中,上例中的?foo?與?bar?都是左值,因為它們總是能夠出現(xiàn)在賦值符號的左側(cè)。
看下面的代碼:
第三行的?printf?語句中的?*bar?也是一個左值,因為它指代了一個有名字的存儲空間,這個存儲空間的名字就叫做*bar。這個存儲空間其實就是以?foo?為基地址的存儲空間。在表達式?*bar?中,?*?號的作用是解引用,就是將以?bar為基地址的內(nèi)存空間中存儲的內(nèi)存地址取出來,然后去訪問這個內(nèi)存地址對應(yīng)的內(nèi)存空間。由于?*bar?的類型是?int,所以程序自身就可以知道要訪問的是以?*bar?為基地址的 4 個字節(jié),因此它可以準確無誤的將整型數(shù)據(jù)?10?取出來并交給printf?來顯示。
指針最黑暗之處在于,當你拿到了一塊內(nèi)存空間的基地址之后,你可以借助這個基地址隨意訪問內(nèi)存中的任何區(qū)域!也就是說,你可以從通過指針獲得內(nèi)存空 間的入口,然后你可以讓你的程序在內(nèi)存中(棧空間)隨便逛,隨便破壞,然后你的程序可能就崩潰了。你的程序如果隱含緩沖區(qū)溢出漏洞,它甚至可被其他程序控 制著去執(zhí)行一些對你的系統(tǒng)非常不利的代碼,這就是所謂的緩沖區(qū)溢出攻擊。C 語言不提供任何緩沖區(qū)保護機制,能否有效保護緩沖區(qū),主要取決于你的 C 編程技藝。
現(xiàn)在我們寫 C 程序時,基本上不需要擔心自己的程序會遭遇緩沖區(qū)溢出攻擊。因為只有那些被廣泛使用的 C 程序才有這種風險;如果很不幸,你寫的 C 程序真的被很多人使用了,那也不需要太擔心。《深入理解計算機系統(tǒng)》在 3.12 節(jié)『存儲器的越界引用和緩沖區(qū)溢出』中告訴我們,現(xiàn)代操作系統(tǒng)對程序運行時所需要的棧空間是隨機生成的,導致攻擊者很難獲得棧空間中的某個確定地址,至少 在 Linux 系統(tǒng)中是這樣子。C 語言編譯器提供了棧破壞檢測——至少在 GCC 中是這樣,其原理就是程序的棧空間放置了一只『金絲雀』,程序在運行中一旦發(fā)現(xiàn)有襲擊『金絲雀』的可恥代碼,它就會異常終止。處理器層面也對可執(zhí)行代碼所 在的內(nèi)存區(qū)域進行了限定,這樣攻擊者很難再向程序的棧空間插入攻擊系統(tǒng)的可執(zhí)行代碼了。
棧與堆
如果我說 C 語言是一種部分支持垃圾內(nèi)存回收的語言……你可能會認為我腦子壞掉了。事實上,C 語言中的所有的局部變量包括指針超出作用域時,它們所占據(jù)的存儲空間都會被『回收』。這算不算內(nèi)存垃圾回收?
從 C 程序的角度來看,內(nèi)存并非一個以字節(jié)為單位的一個很大但是又經(jīng)常不夠用的空間,不是一個,而是兩個。其中一個空間叫棧,另一個空間叫堆。可被 C 程序『回收』存儲空間是棧空間。也就是說,在一個函數(shù)中,所有的局部變量所占據(jù)的存儲空間屬于棧空間。可能再說的學術(shù)一點,就是所有的左值都在棧空間(我 不確定這樣說到底是不是正確)。
當一個函數(shù)運行結(jié)束,它所占據(jù)的棧空間就不再屬于它了,而是將會被一個新的待運行的函數(shù)占據(jù)。所以,從本質(zhì)上說,C 程序?qū)?臻g的回收都不屑一顧,因為它根本不回收,而是舊的數(shù)據(jù)會被新的數(shù)據(jù)覆蓋。
堆空間,我們在程序里無法直接訪問,只能借助指針。因為堆空間的內(nèi)存地址可被指針引用。例如,當使用?malloc?分配空間時,所分配空間的基地址總是保存在一個位于棧空間的指針中的。
棧空間通常遠遠小于堆空間,即便如此也幾乎不會出現(xiàn)某個函數(shù)會耗盡棧空間的現(xiàn)象。如果這種現(xiàn)象出現(xiàn)了,那只能證明造出這種現(xiàn)象的程序猿應(yīng)該繼續(xù)學習 C 語言了。棧空間被耗盡,往往是因為有些程序本來是寫成遞歸,但可能是代碼寫錯了,導致遞而不歸;還有一種可能是遞歸層次太深,這時可以想辦法在堆空間中模 擬一個棧來解決。還有一種情況就是在函數(shù)中定義了很大的數(shù)組,導致棧空間放不下……這種情況總是可以靠分配堆空間來解決。
數(shù)據(jù)的抽象
當你具備了一些 C 編程基礎(chǔ),并且能夠理解上文中的內(nèi)容,那么你就可以對各種類型的數(shù)據(jù)進行抽象了。
我們?yōu)槭裁匆獙?shù)據(jù)進行抽象?《計算機程序的構(gòu)造和解釋》的第 2 章的導言部分給出了很好的答案,即:許多程序在設(shè)計時就是為了模擬復(fù)雜的現(xiàn)象,因為它們就常常需要構(gòu)造出一些運算對象,為了能夠模擬真實世界中的現(xiàn)象的各個方面,需要將運算對象表示為一些組件的復(fù)合結(jié)構(gòu)。
下面來對自行車鏈的任意一個鏈節(jié)進行模擬:
然后我們可以造出 3 個鏈節(jié),然后可以造出世界上最短的車鏈:
如果再多造一些鏈節(jié),就可以得到周長大一些的車鏈,也能夠制造出各種形狀的多邊形,但是最好是借助無名的內(nèi)存空間。下面的代碼可以創(chuàng)建一條具有 1000 個鏈節(jié)的鏈條:
如果我們將前面那個示例中的?a,b,?c?視為三角形的三個頂點,那么我們所創(chuàng)造的三個鏈節(jié)構(gòu)成的鏈條就變成了一個三角形。同理,上述所創(chuàng)建的 1000 個鏈節(jié)的鏈條就變成了一個 1000 條邊首尾相接的多邊形。如果學過拓撲學,那么自然可以發(fā)現(xiàn)任何與圓環(huán)同胚的結(jié)構(gòu)都可以基于?struct chain_node?這種數(shù)據(jù)結(jié)構(gòu)模擬出來,而我們所仰仗的東西僅僅是將三個指針封裝到一個結(jié)構(gòu)體中。
事實上,struct chain_node?中的第三個指針?void *shape?還沒被用到。這是一個?void *?類型的指針,是喜歡用 C 代碼玩各種抽象的程序猿的最愛,因為它能引用任何類型數(shù)據(jù)所在內(nèi)存空間的基地址。這就意味著?struct chain_node?可以借助?shape?指針獲得強大的擴展能力。
現(xiàn)在,我要制造一種很簡陋的鏈節(jié),它的形狀僅僅是一個矩形的小鐵片,上面打了兩個小圓孔。我將它的數(shù)據(jù)結(jié)構(gòu)設(shè)計為:
基于這些數(shù)據(jù)結(jié)構(gòu),我就可以寫出一個專門用來制造矩形小鐵片的函數(shù):
然后再為?create_chain_node_shape?所接受的兩種參數(shù)寫出相應(yīng)的構(gòu)造函數(shù):
為了讓?create_circle?更方便使用,最好再創(chuàng)建一個?struct point?的構(gòu)造函數(shù):
一切所需要的構(gòu)件都已準備完畢,現(xiàn)在可以開始生產(chǎn)某種特定型號的鏈節(jié)了,即:
最后再將制造鏈條的代碼略作修改:
現(xiàn)在我們所模擬的車鏈與現(xiàn)實中的車鏈已經(jīng)有些形似了。上述代碼雖然有些冗長,下文會對其進行重構(gòu),現(xiàn)在先來總結(jié)一下上述代碼中指針的用法。
仔細觀察上述代碼中我們所定義的結(jié)構(gòu)體,它們的共同特征是:所有非 C 內(nèi)建的數(shù)據(jù)類型都是結(jié)構(gòu)體類型,當它們作為某個結(jié)構(gòu)體成員類型時均被聲明為指針類型。為什么要這樣?如果你真的打算問這個問題,那么就請你觀察一下上述的 5 個create_xxx?函數(shù),你會發(fā)現(xiàn)這些?create?函數(shù)的參數(shù)與返回值也都是結(jié)構(gòu)體類型的指針。將這些現(xiàn)象綜合起來,可以得出以下結(jié)論:
將結(jié)構(gòu)體指針作為函數(shù)的參數(shù)與返回值,可以避免函數(shù)調(diào)用時發(fā)生過多的內(nèi)存復(fù)制。
當一個結(jié)構(gòu)體類型作為其他結(jié)構(gòu)體的成員類型時,將前者聲明為指針類型,可以在后者的?create?函數(shù)中避免繁瑣的解引用。
void *?指針可以引用任意類型的數(shù)據(jù)存儲空間的基地址。例如在?create_chain_node?函數(shù)的定義中,我們將一個struct chain_node_shape?類型的指針賦給了?void *?類型的指針?shape。
這三條結(jié)論是指針在數(shù)據(jù)抽象中的慣用手法,它不僅關(guān)系到數(shù)據(jù)結(jié)構(gòu)的設(shè)計,也關(guān)系到數(shù)據(jù)結(jié)構(gòu)的構(gòu)造與銷毀函數(shù)的設(shè)計。(上述代碼為了省事,沒有定義數(shù)據(jù)結(jié)構(gòu)的銷毀函數(shù))
數(shù)據(jù)再抽象
上一節(jié)的代碼有些冗長,我們可以嘗試對其進行精簡。首先看下面這三個結(jié)構(gòu)體及其?create?函數(shù):
顯然,這些代碼長的太像了!那四個結(jié)構(gòu)體都是存儲兩個成員的結(jié)構(gòu)體,而相應(yīng)的?create?函數(shù)也無非是將函數(shù)所接受的參數(shù)保存到結(jié)構(gòu)體成員中。有沒有辦法用很少的代碼來表示它們?有!
既然每個結(jié)構(gòu)體都保存 2 個成員,那么我們就先將上述代碼刪掉,然后定義一個?pair?類型的結(jié)構(gòu)體:
在?pair?結(jié)構(gòu)體中,我們用了兩個?void *?指針,只有如此我們方能很自信的說?pair?可以存儲任意類型的兩個數(shù)據(jù)。接下來,只需修改?create_chain_node?函數(shù)的定義:
我勇敢的承認這個基于?struct pair?的?create_chain_node?函數(shù)太丑陋了,但是我們總算是消除了大量的結(jié)構(gòu)體及其構(gòu)造函數(shù)了,而且整體代碼量減少了大約 1/6。
仔細觀察上述代碼,顯然下面的三段代碼存在著高度的重復(fù):
這三段代碼都在向?pair?結(jié)構(gòu)體中存入兩個?double *?類型的數(shù)據(jù)。既然如此,我們可以專門寫一個函數(shù),讓它生成面向double *?的?pair?結(jié)構(gòu)體,即:
然后再次重構(gòu)?create_chain_node?函數(shù):
山重水復(fù)疑無路
經(jīng)過再次重構(gòu)后的?create_chain_node?看上去要好了一些,但是依然有兩段代碼存在高度重復(fù):
但是僅從?pair?結(jié)果體層面已經(jīng)無法對這兩段代碼進行簡化了,而且我又非常不想寫一個像下面這樣的輔助函數(shù):
雖然?create_hole?能夠?qū)⑸鲜鰞啥沃貜?fù)的代碼簡化為:
但是與?pair_for_double_type?函數(shù)相比,create_hole?這個函數(shù)的應(yīng)用范圍非常狹小。由于?pair_for_double_type函數(shù)可以將兩個?double?類型的數(shù)據(jù)存儲到?pair?結(jié)構(gòu)體中,在我們的例子中創(chuàng)建二維點與矩形可以用到它,在科學計算中創(chuàng)建極坐標、復(fù)數(shù)以及所有的二次曲線方程式也都都能用到它,但是?create_hole?卻只能在創(chuàng)建車鏈這件事上有點用處。也就是說,正是因為?pair_for_double_type?函數(shù)所取得的成功,導致我們認為?create_hole?的品味太低。我們應(yīng)該想一想還有沒有其他途徑可以消除上述代碼的重復(fù)。
仔細分析?left_hole?與?right_hole?的構(gòu)造過程,不難發(fā)現(xiàn)?hole?的?center?與?radius?這兩種數(shù)據(jù)的類型不一致是造成我們難以對上述重復(fù)的代碼進行有效簡化的主要原因,create_hole?之所以能夠?qū)ι鲜鲋貜?fù)的代碼進行大幅簡化,是因為它根據(jù)我們的問題構(gòu)造了一個特殊的?pair?結(jié)構(gòu)體——姑且稱之為 X。X 結(jié)構(gòu)體的特殊指出在于其?first?指針存儲的是一個面向?double *?的同構(gòu)類型的?pair?結(jié)構(gòu)體,其?second?指針則存儲了一個?double?類型數(shù)據(jù)的基地址。正是因為 X 的結(jié)構(gòu)太特殊了,所以導致?create_hole?這種抽象的應(yīng)用范圍過于狹隘,以至于現(xiàn)實中只有圓形比較符合這種結(jié)構(gòu)體。
既然是異構(gòu)的?pair,而我們已經(jīng)實現(xiàn)了一個可以創(chuàng)建存儲?double?類型數(shù)據(jù)的?pair?的函數(shù)?pair_for_double_type,這個函數(shù)的結(jié)果是可以直接存入異構(gòu)?pair?中的。現(xiàn)在我們?nèi)鄙僦皇且粋€可以將?double?值轉(zhuǎn)化為可直接存入異構(gòu)?pair的函數(shù),即:
有了這個函數(shù),就可以對?create_chain_node?繼續(xù)進行簡化了:
而且,基于?malloc_double?函數(shù),還能對?pair_for_double_type?函數(shù)進行簡化:
事實上,如果我們再有一個這樣的函數(shù):
還能對?reate_chain_node?再做一步簡化:
看到了吧,只要略微換個角度,很多看似難以簡化的代碼都能得以簡化。這個簡化的過程一直是在指針的幫助下進行的,但事實上,當你的注意力一直集中在 怎么對代碼進行簡化時,指針的使用簡直就是本能一樣的存在,以至于你覺得你并沒有借助指針的任何力量,完全是你自己的邏輯在指導著你的行為。在這個過程 中,無論是面向?qū)ο筮€是面向模板,都很難將你從冗長的代碼中拯救出來……
面向什么,可能就會失去未面向的那些
在上文中模擬車鏈的程序中,我一開始是用面向?qū)ο蟮姆绞絹韺懙?#xff0c;所以我造出了 5 個結(jié)構(gòu)體,分別描述了二維點、矩形、圓形、鏈節(jié)形狀以及鏈節(jié)等對象,結(jié)果卻出現(xiàn)了一大堆繁瑣的代碼。雖然面向?qū)ο缶幊?#xff0c;在思維上是非常簡單的,那就是現(xiàn)實 中有什么,我們就模擬什么。但是你認真思考一下,現(xiàn)實中其實很多東西都有共性,如果你傻乎乎的去逐個模擬,而忽略它們的共性,那么你的代碼絕對會非常臃 腫。
當然,面向?qū)ο缶幊桃蔡岢珡乃M的事物中提取共性,然后借助繼承的方式來簡化代碼。但是一旦信仰了類與繼承,你能做的最好的抽象就是對某一類事物 進行抽象,比如你能夠?qū)Α很嚒活惖氖挛镞M行抽象,但是你卻無法將對『飛機』和『車』這兩類中的事物進行抽象。顯然,飛機與車是有共性的,例如它們都能載 客,都有儀表盤,都有窗戶,都有座位,都有服務(wù)員……
當我發(fā)現(xiàn)基于面向?qū)ο髣?chuàng)造的那些結(jié)構(gòu)體存在著一個共性——它們都包含著兩個成員,很自然的就會想到我應(yīng)該制造一個包含著兩個任意類型的結(jié)構(gòu)體?pair,然后用?pair?來容納我需要的數(shù)據(jù)。當面向?qū)ο缶幊谭妒皆谀愕乃枷胫懈畹俟?#xff0c;這種簡單的現(xiàn)象往往會被忽略的,特別是你已經(jīng)滿足于你寫的程序已經(jīng)能夠成功的運行之時。
接下來,當我試圖用?pair?結(jié)構(gòu)體取代二維點、矩形、圓形、鏈節(jié)形狀等結(jié)構(gòu)體的時候,我就開始走上了『泛型』的道路。C 語言里沒有 C++ 模板這種工具可以用,所以我只能依賴?void *,而且為了簡化?double?類型的數(shù)據(jù)向?void *?的轉(zhuǎn)化,所以定義了:
如果你對 C++ 的泛型編程有所了解,一定會覺得?pair_for_double_type?函數(shù)其實就是對?pair?進行特化。因為本來我是希望?pair?能存儲任意類型的數(shù)據(jù)的,但是現(xiàn)在我需要頻繁的用它來存儲一對?double?類型的數(shù)據(jù),那么我就應(yīng)該去制造一個專用的?pair?結(jié)構(gòu)。
當我發(fā)現(xiàn)我需要頻繁的產(chǎn)生?pair?實例,并向它的?first?與?second?指針中存儲某些類型的數(shù)據(jù)存儲空間的基地址,所以我就將這種共性抽象為:
最終使得?create_chain_node?函數(shù)的定義即簡潔又清晰:
原來我用面向?qū)ο缶幊谭妒剿鶎懙拇a是 104 行,換成泛型編程范式所寫的代碼是 75 行。那么我可以斷定,是泛型編程拯救了面向?qū)ο髥?#xff1f;當然不能!因為我們的程序還沒有寫完,我們還需要面向?qū)ο蟆?/p>
對象的回歸
先擺出?create_chain_node?函數(shù):
create_chain_node?函數(shù)可以創(chuàng)建鏈節(jié),它是借助很抽象的?pair?結(jié)構(gòu)體將很多種類型的數(shù)據(jù)層層封裝到了?chain+node結(jié)構(gòu)體中,那么我們?nèi)绾螐?chain_node?結(jié)構(gòu)體中提取這些數(shù)據(jù),并使之重現(xiàn)它們所模擬的現(xiàn)實事物?
例如,我們怎樣從?chain_node?結(jié)構(gòu)體中獲取一個?left_hole?的信息?顯然,下面的代碼
并不能解決我們的問題,因為?left_hole?中只是兩個?void *?指針,而我們需要知道的是?left_hole?的中心與半徑。那么我們繼續(xù):
依然沒有解決我們的問題,因為我們想要的是?left_hole?的中心,而不是一個包含著兩個?void *?指針的?center,所以需要繼續(xù):
最后我們得到了三個?double?類型的數(shù)據(jù),即?center_x,?center_y,?radius,于是似乎我們的任務(wù)完成了,但是你如何將上述過程寫成一個函數(shù)?get_left_hole? C 語言中的函數(shù)只能有一個返回值。如果通過函數(shù)的參數(shù)來返回一些值,那么get_left_hole?是能寫出來的,例如:
但是,如果你真的這么寫了,那只能說明再好的編程語言也無法挽救你的品味。
我們應(yīng)該繼續(xù)挖掘指針的功能,像下面這樣定義?get_left_hole會更好一些:
好在哪?我們充分利用了 C 編譯器對數(shù)據(jù)類型的隱式轉(zhuǎn)換,這實際上就是 C 編譯器的一種編譯期計算。這樣做可以避免在代碼中出現(xiàn)?*((double *)(...))?這樣的代碼。void *?指針總是能通過賦值語句自動轉(zhuǎn)換為左值的,前提是你需要保證左值的類型就是?void *?的原有類型。這是 C 語言的一條清規(guī)戒律,不能遵守這條戒律的程序猿,也許再好的編程語言也無法挽救他。
C++ 這個叛徒,所以無論它有多么強大,也無法拯救那些無法保證左值的類型就是?void *?原有類型的程序猿。用 C++ 編譯器迫使程序猿必須將
寫成:
否則代碼就無法通過編譯。這樣做,除了讓代碼更加混亂之外,依然無法挽救那些無法保證左值的類型就是?void *?原有類型的程序猿,只會讓他們對裸指針以及類型轉(zhuǎn)換這些事非常畏懼,逐漸就走上了惟類型安全的形而上學的道路。C++ 11 帶來了新的智能指針以及右值引用,希望他們能得到這些新 C++ 式的拯救吧。
當我們用面向?qū)ο蟮乃悸穼崿F(xiàn)了?get_left_hole?之后,就可以像下面這樣使用它:
一切都建立在指針上了,只是在最后要輸出數(shù)據(jù)的需用?*?對指針進行解引用。
上述代碼中有個特點,left_hole?并不占用內(nèi)存,它僅僅是對?t?所引用的內(nèi)存空間的再度引用。可能有人會擔心left_hole?具有直接訪問?t?所引用的內(nèi)存空間的能力是非常危險的……有什么危險呢?你只需要清楚?left_hole?只是對其他空間的引用,而這一點自從你用了指針之后就已經(jīng)建立了這樣的直覺了,你想修改?left_hole?所引用的內(nèi)存空間中的數(shù)據(jù),就可以 do it,不想修改就不去 do it,這有何難?如果自己并不打算去修改?left_hole?所引用的內(nèi)存空間中的數(shù)據(jù),但是又擔心自己或他人會因為失誤而修改了這些數(shù)據(jù)……你應(yīng)該將這些擔心寫到?get_left_hole?的注釋里!
對于只需要稍加注意就可以很大程度上避免掉的事,非要從編程語言的語法層面來避免,這真的是小題大作了。如果我們在編程中對于?void *?指針的隱式類型正確轉(zhuǎn)換率高達 99%,為何要為 1% 的失誤而修改編程語言,使之充滿各種巧妙迂回的技巧并使得代碼愈加晦澀難懂呢?
《C 陷阱與缺陷》的作者給出了一個很好的比喻,在烹飪時,你用菜刀的時候是否失手切傷過自己的手?怎樣改進菜刀讓它在使用中更安全?你是否愿意使用這樣一把經(jīng) 過改良的菜刀?作者給出的答案是:我們很容易想到辦法讓一個工具更安全,代價是原來簡單的工具現(xiàn)在要變得復(fù)雜一些。食品加工機一般有連鎖裝置,可以保護使 用者的手指不會受傷。然而菜刀卻不同,如果給菜刀這種簡單、靈活的工具安裝可以保護手指的裝置,只能讓它失去簡單性與靈活性。實際上,這樣做得到的結(jié)果也 許是一臺食品加工機,而不再是一把菜刀。
我成功的將本節(jié)的題目歪到了指針上。現(xiàn)在再歪回來,我們來談?wù)剬ο蟆F鋵嵰呀?jīng)沒什么好談的了,get_left_hole?返回的是泛型指針的類型具化,借助這種類型具化的指針我們可以有效避免對?pair?中的?void *?指針進行類型轉(zhuǎn)換的繁瑣過程。
將函數(shù)變成數(shù)據(jù)
再來看一下經(jīng)過大幅簡化的?create_chain_node?函數(shù):
這個函數(shù)對于我們的示例而言,沒有什么問題,但是它只能產(chǎn)生特定形狀的鏈節(jié),這顯然不夠通用。如果我們想更換一下鏈節(jié)的形狀,例如將原來的帶兩個小孔的矩形鐵片換成帶兩個小孔的橢圓形鐵片,那么我們將不得不重寫一個create_elliptic_chain_node?函數(shù)。當我們這樣做的時候,很容易發(fā)現(xiàn)?create_elliptic_chain_node?函數(shù)中同樣需要下面這段代碼:
如果我們要生產(chǎn) 100 種形狀的鏈節(jié),那么上述代碼在不同的鏈節(jié)構(gòu)造函數(shù)的實現(xiàn)中要重復(fù)出現(xiàn) 100 次,這樣肯定不夠好,因為會出現(xiàn) 500 行重復(fù)的代碼。太多的重復(fù)的代碼,這是對程序猿的最大的羞辱。
面向?qū)ο蟮某绦蛟晨赡軙氲?#xff0c;我們可以為?chain_node?做一個基類,然后將上述共同的代碼封裝到基類的構(gòu)造函數(shù),然后在各個?chain_node?各個派生類的構(gòu)造函數(shù)中制造不同形狀的鏈節(jié)……在你要將事情搞復(fù)雜之前,建議先看一下這樣的代碼:
看到了吧,我將?create_chain_node?函數(shù)原定義中負責創(chuàng)建鏈節(jié)形狀的代碼全部的抽離了出去,將它們封裝到rectangle_shape?函數(shù)中,然后再讓?create_chain_node?函數(shù)接受一個函數(shù)指針形式的參數(shù)。這樣,當我們需要創(chuàng)建帶兩個小孔的矩形形狀的鏈節(jié)時,只需:
struct chain_node *rect_chain_node = create_chain_node(rectangle_shape);
如果我們像創(chuàng)建帶兩個小孔的橢圓形狀的鏈節(jié),可以先定義一個?elliptic_shape?函數(shù),然后將其作為參數(shù)傳給create_chain_node,即:
struct chain_node *elliptic_chain_node = create_chain_node(elliptic_shape);
這樣做,豈不是要比弄出一大堆類與繼承的代碼更簡潔有效嗎?
在 C 語言中,函數(shù)名也是一種指針,它引用了函數(shù)代碼所在內(nèi)存空間的基地址。所以,我們可以將?rectangle_shape?這樣函數(shù)作為參數(shù)傳遞給?create_chain_node?函數(shù),然后在后者中調(diào)用前者。
由于我們已經(jīng)將?chain_node?結(jié)構(gòu)體中的?shape?指針定義為?void *?指針了,因此對于?create_chain_node?函數(shù)所接受的函數(shù),其返回值是?void *?沒什么問題。不僅沒問題,更重要的是?void *(*fp)(void)?對所有不接受參數(shù)且返回指針類型數(shù)據(jù)的函數(shù)的一種抽象。這意味著對于鏈節(jié)的形狀,無論它的形狀有多么特殊,我們總是能夠定義一個不接受參數(shù)且返回指針的函數(shù)來產(chǎn)生這種形狀,于是?create_chain_node?函數(shù)就因此具備了無限的擴展能力。
如果阿基米的德還活著,也許他會豪放的說,給我一個函數(shù)指針與一個?void *,我就能描述宇宙!
代碼簡化的基本原則
當你采用一切都是對象的世界觀編寫代碼時,一旦發(fā)現(xiàn)一些類之間存在著共性的數(shù)據(jù)抽象,這往往意味著你需要創(chuàng)造一種泛型的數(shù)據(jù)容器,然后用這種容器與具體類型的數(shù)據(jù)的組合來消除那些類。
當你打算從泛型的數(shù)據(jù)容器中取數(shù)據(jù),并希望所取的數(shù)據(jù)能夠直觀的模擬現(xiàn)實中的事物時,這往往意味著你要創(chuàng)造一些數(shù)據(jù)結(jié)構(gòu),然后讓泛型的數(shù)據(jù)容器中存 儲的數(shù)據(jù)流入這些數(shù)據(jù)結(jié)構(gòu)中,從而轉(zhuǎn)化為有類型且具名的數(shù)據(jù)。這些數(shù)據(jù)結(jié)構(gòu)就類似于各種各樣的觀察器或 Parser,我們通過它們解讀或修改泛型容器中的數(shù)據(jù)。
當某個函數(shù)?f?中有一部分代碼是與具體的問題息息相關(guān),而另一部分代碼則與具體的問題無關(guān)。為了讓這個函數(shù)具備強大的擴展性,你需要將那些與具體問題息息相關(guān)的代碼抽離到專用的函數(shù)中,然后再將這些專用函數(shù)傳遞給?f。
回避 C 指針是要付出代價的
在 C 語言中,在執(zhí)行這些基本原則時,指針是最簡單明快的工具,像是著名廚師庖丁手里的刀。在靜態(tài)類型語言中,任何企圖回避指針的行為,必然會導致編程語言的語法復(fù)雜化或者削弱語言的表達能力。
在 C++ 中為了回避指針,發(fā)明了引用——本質(zhì)上一種被弱化了的指針,結(jié)果導致 C++ 初學者經(jīng)常要問『什么時候用指針,什么時候用引用』這樣的問題。在智能指針未問世之前,STL 提供的泛型容器無法存儲引用,為了避免在容器中存儲對象時發(fā)生過多的內(nèi)存復(fù)制,往往需要將指針存到容器中。當某個函數(shù)在內(nèi)部創(chuàng)建了一個比較大的對象時,這 個函數(shù)想將這個對象傳遞給其他對象時,這時如果不借助指針,那只能是將這個大對象作為返回值,然后引發(fā)了對象數(shù)據(jù)不止一次被復(fù)制的過程。如果在函數(shù)中?new?一 個大對象,然后以指針的形式將其返回,這又與 C++ 一直想向用戶掩蓋指針的理想發(fā)生了矛盾……為了解決這個問題,終于在 C++ 11 里搞出來一個挺復(fù)雜挺扭曲的右值引用的辦法,解決了在類的復(fù)制構(gòu)造函數(shù)中偷偷的使用指針,但是類的用戶卻看不到指針這樣的問題……
Java 回避指針的策略比 C++ 要高明一些。在 Java 中,即沒有指針也沒有引用。只要是類的實例(對象),無論是將其作為參數(shù)傳遞給函數(shù),還是作為函數(shù)的返回值,還是將其復(fù)制給同類的其他對象,都是在傳地 址,而不是在傳值。也就是說,Java 將所有的類實例都潛在的作為指針來用的,只有那些基本類型才是作為值來傳遞的。這種對數(shù)據(jù)類型進行了明確的區(qū)分的態(tài)度是值得點贊的,但是當 Java 想將一個函數(shù)(方法)傳遞給另一個函數(shù)(方法)時,代碼就出現(xiàn)了扭曲,完全不能做到像 C 語言以指針的形式傳遞函數(shù)那樣簡潔直觀。
C# 在指針的處理上似乎要比 C++ 與 Java 好得多,但是將那些使用指針的代碼標定為?unsafe,這是一種歧視。類似于『嗟,來食!』。廉者不受嗟來之食。
在動態(tài)類型語言中,例如 Python,據(jù)說是一切皆引用,這樣很好。也可以直接將一個函數(shù)作為參數(shù)傳遞給另一個函數(shù),甚至還能在一個函數(shù)中返回一個函數(shù),這樣更好。動態(tài)類型語言 在語法、抽象能力、類型安全以及資源管理方面很大程度上超越了 C、C++、Java 這些靜態(tài)類型語言,但是用前者編寫的程序的計算速度卻往往比后者慢上一倍。
沒有完美的指針,也不會有完美的編程語言,這一切皆因我們是在機器上編程,而不是在我們的大腦里編程。
C 程序猿的指針信條
篡改《步槍兵信條》,自娛自樂。
這是我的指針。雖有很多相似的,但這個是我的。我的指針是我的摯友,如同我的生命。我將運用它如同運用我的生命。指針沒了我便是廢物,我沒了指針便成為廢人。我將準確無誤的使用我的指針,我將比敵人用的更好,我將在他的程序速度超過我之前超過他,我會超過他的。
我與我的指針知道,編程中不論動用多么優(yōu)雅的語言,動用多么強大的標準庫,面向多么強大的編程范式,都是沒意義的。只有解決問題才有意義。我們會解決的。
我的指針是人性的,就像我一樣,因為它如同我的生命。因此我將像對兄弟一樣地了解它。我將了解它的弱點,它的強項,它的構(gòu)成,它所指的和指向它的。我將對指針持續(xù)建立完善的知識與技藝,使它們就如同我一般整裝待發(fā)。我們會成為彼此的一部分。
在上帝面前我對這信條宣誓。我與我的指針是計算機的守衛(wèi)者,我們是問題的克星,我們將拯救我的程序。但愿如此,直到不需要編程,沒有問題,只有休息。
來源:51CTO
總結(jié)
以上是生活随笔為你收集整理的我们来谈谈面向指针编程的那些事的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 全球最大保险公司之一Ace推出一亿美元网
- 下一篇: 《认知设计:提升学习体验的艺术》——小结