孟繁超，葉會英

（鄭州大學(xué) 信息工程學(xué)院，河南 鄭州 450001）

0 引 言

隨著面向?qū)ο蟮木幊趟枷耄╫bject oriented programming）的推廣與普及，C 語言在數(shù)據(jù)封裝上的缺點也日益凸顯。為了解決這一問題，Bjarne Stroustrup于20世紀(jì)80年代發(fā)明了C＋＋語言。C＋＋語言在不斷發(fā)展和改進的同時，由于引入了過多的特性，其依舊存在語法過于冗雜，標(biāo)準(zhǔn)不統(tǒng)一等問題，這也使得其在一些硬件受限設(shè)備中以及系統(tǒng)級編程中并不適用。

雖然C語言本身對面向?qū)ο蟮奶匦灾С钟邢?，但這并不影響面向?qū)ο蟮乃枷朐贑 語言中的應(yīng)用。實際中，可借助代碼生成工具或代碼擴展工具配合一定的代碼規(guī)范或設(shè)計模式進行模擬，從而提高C 程序的可重用性。在桌面Linux系統(tǒng)中廣泛使用的GNOME 界面系統(tǒng)是C 語言應(yīng)用面向?qū)ο笏枷氲囊粋€代表，其底層的GObject庫提供了一套完善的面向?qū)ο蟮念愋拖到y(tǒng)。而早在早在C＋＋創(chuàng)立之初，Bjarne Stroustrup也曾嘗試過用類似的方法對C語言進行改造［1－2］。

在C89標(biāo)準(zhǔn)［3］中增加了泛型指針以及C99標(biāo)準(zhǔn)［4］中增加可變宏參數(shù)、結(jié)構(gòu)體初始化等特性的支持之后，C 語言的元編程能力得以進一步的加強。合理的利用現(xiàn)代編譯器的這些特性，配合專門設(shè)計的對象模型，可以將部分C＋＋在編譯時完成的動作讓C 語言在運行時來進行，進而可以在保證易用性的同時為C 語言增加對封裝、繼承和多態(tài)等特性的支持。實際中，利用托管于Google Code的OOCGCC項目［5］中的代碼，可以完成對面向?qū)ο笏枷氲哪M，且能夠很好的適用于AVR，STM32等一些嵌入式平臺。

1 對象模型的內(nèi)存分布

1.1 C＋＋的對象模型

無論何種編程語言，只要其具備面向?qū)ο蟮奶匦?，都需要專門為其設(shè)計特定的對象模型。為了方便說明，這里以一個C＋＋類為例引出幾種常規(guī)的對象模型的設(shè)計。

在C＋＋中，類的成員有兩種內(nèi)存屬性，靜態(tài)的（static）和非靜態(tài)的（non－static）。而類的方法則有3種內(nèi)存屬性，靜態(tài)的（static），非靜態(tài)的（non－static）以及虛擬的（virtual）。

現(xiàn)假定有一用C＋＋定義的類如圖1所示。

圖1 C＋＋類示例

而圖1例子中涵蓋了這些不同屬性的方法和成員，其內(nèi)存分布［6］情況如圖2所示。

圖2 C＋＋內(nèi)存模型

C＋＋的對象模型中有相當(dāng)一部分內(nèi)存空間是在編譯時獨立分配的，同時如果某個類有以virtual關(guān)鍵字聲明的方法（圖1中為虛析構(gòu)方法）則該模型會具備獨立的虛表結(jié)構(gòu)，且在虛表結(jié)構(gòu)中還擁有一個提供RTTI（RunTime type information）特性的類型信息區(qū)域。

借助于編譯器，C＋＋可以保證使用時代碼的簡潔性，但如果要使用C語言直接去實現(xiàn)這樣的對象模型，因為要將編譯時的工作轉(zhuǎn)移至運行時來做，必然會引入大量額外的附加代碼。為此，必須對該模型進行改良，以適應(yīng)C 語言的某些特性。

1.2 適用于C語言的對象模型

用C語言去模擬面向?qū)ο蟮奶匦杂泻芏喾绞剑灾刑峒暗腉Object庫雖然模擬了很多面向?qū)ο蟮奶匦裕@種模擬因為引入了過多的特性而在實際使用時顯得非常繁瑣［7－8］。為了在功能和易用性之間尋求一種平衡，OOCGCC項目中設(shè)計并實現(xiàn)了一種新的對象模型，利用現(xiàn)代C編譯器的特性同時結(jié)合元編程技巧，在模擬了面向?qū)ο蟮幕咎匦缘耐瑫r，保證了易用性，簡化了開發(fā)的復(fù)雜度。對應(yīng)于圖1 中的例子，這種新的模型的內(nèi)存分布如圖3所示。

和圖2中C＋＋對象模型一樣的是，將虛表結(jié)構(gòu)和實例結(jié)構(gòu)分離，這樣可以有效的區(qū)分成員和方法，有助于內(nèi)存的節(jié)約。和C＋＋模型的主要不同是將cnt成員放在虛表結(jié)構(gòu)中并在虛表結(jié)構(gòu)中保留了指向方法的指針。同時，在虛表結(jié)構(gòu)中增加了一個實例計數(shù)用的成員。而對于類的方法，因為C語言無法直接去調(diào)用，故在虛表結(jié)構(gòu)中保留了指向其真實函數(shù)地址的函數(shù)指針。

圖3 OOC－GCC的內(nèi)存模型

因為不能借助于編譯器，OOC－GCC項目并沒有實現(xiàn)完整的類型系統(tǒng)，故省略了C＋＋模型中和類型信息相關(guān)的結(jié)構(gòu)，但并不影響對面向?qū)ο笾蟹庋b，繼承，多態(tài)等特性的模擬。如果需要對類型系統(tǒng)的模擬，也可配合GObject中的類型系統(tǒng)使用。

1.3 支持單根繼承的對象模型

現(xiàn)假設(shè)一個類B繼承了圖1中所表述的類A，那么按照本文中提出的內(nèi)存模型，其具體內(nèi)存分配如圖4所示。

圖4 OOC－GCC單根繼承對象模型

2 對象模型的使用

圖4中看似復(fù)雜的內(nèi)存布局，可配合表1中所定義的一些宏一起使用，無需經(jīng)過任何第三方工具即可實現(xiàn)類的設(shè)計與使用。

表1 OOC－GCC宏的定義

B的實例部分繼承了A的實例部分的內(nèi)容，而B的虛表結(jié)構(gòu)繼承了A的虛表結(jié)構(gòu)的內(nèi)容，但虛表結(jié)構(gòu)頭部的析構(gòu)指針和實例計數(shù)器部分保持不變。在B的實例中保留有兩個虛表指針，分別指向A的虛表結(jié)構(gòu)以及B的虛表結(jié)構(gòu)。這意味著，即使在沒有分配A的實例的前提下，直接聲明一個B的實例，會同時為之分配A和B的兩個虛表結(jié)構(gòu)，而B的虛表結(jié)構(gòu)因為繼承的原因，也包含了A的虛表結(jié)構(gòu)的內(nèi)容。

在設(shè)計一個類時，CLASS宏和STATIC 宏分別用來定義一個類的實例結(jié)構(gòu)和虛表結(jié)構(gòu)，而與之相應(yīng)的CLASS＿EX 宏以及STATIC＿EX 宏則為實例結(jié)構(gòu)和虛表結(jié)構(gòu)的定義增加了對單根繼承特性的支持。ASM和ASM＿EX 則是用來將類的定義與實現(xiàn)的類的構(gòu)造函數(shù)與析構(gòu)函數(shù)進行綁定。

在對一個類進行操作時，表1中定義的NEW 宏和DELETE宏和C＋＋中的new 與delete關(guān)鍵字十分類似，它們都會在堆內(nèi)存上開辟或釋放一塊區(qū)域并進行對象的構(gòu)造與析構(gòu)。NEW0 宏和DELETE0 宏則對應(yīng)NEW 宏和DELETE宏不接收任何參數(shù)的情形。ST 宏則用來通過實例結(jié)構(gòu)獲取指向虛表結(jié)構(gòu)的指針。＊Fn則是對一定形式的函數(shù)指針的類型重定義，如iFn表示返回值為int型的函數(shù)指針，而vFn表示無返回值（返回值為void型）的函數(shù)指針。

使用表1中的宏來描述圖4中定義的類A和類B的代碼如圖5中所示。

3 對象模型的設(shè)計

3.1 功能模塊的設(shè)計

OOC－GCC中的模塊如圖6所示。

OOC－GCC項目由多個模塊構(gòu)成，這些模塊被定義在與模塊名相對應(yīng)的.h或.c文件中。其中，最為核心的部分定義在OOCore模塊中。OOBase模塊則對OOCore模塊進行了擴展，使之支持虛表結(jié)構(gòu)以及單根繼承等特性。對于使用者而言，只需關(guān)注兩個模塊，一個是OOStd模塊，該模塊用于對底層較復(fù)雜的內(nèi)容進行重定義，簡化實際使用時的復(fù)雜度；另一個是OOCfg模塊，該模塊用于對整體進行配置。通過OOCfg模塊中的宏開關(guān)，可以選擇性的使用調(diào)試用的OODbg模塊，也可以開啟對匿名結(jié)構(gòu)體等特性的支持。

3.2 實例結(jié)構(gòu)和虛表結(jié)構(gòu)的設(shè)計

為了使表1中和類的設(shè)計相關(guān)的宏能和圖3中以及圖4中所表述的對象模型相適應(yīng)，當(dāng)使用CLASS，STATIC，CLASS＿EX，STATIC＿EX 宏定義一個類的時候，除了類本身的成員外，還會隱式的引入一些和構(gòu)造與析構(gòu)相關(guān)的成員。

每當(dāng)使用CLASS宏時，都會在一個結(jié)構(gòu)體的頭部放置一個名為OOC＿STRUCT＿＿classRootHead的結(jié)構(gòu)體。相應(yīng)的每當(dāng)使用STATIC宏時，頭部的結(jié)構(gòu)體名為OOC＿STRUCT＿＿staticRootHead。具體的定義如圖7所示。

圖7 頭部結(jié)構(gòu)設(shè)計

每一個用CLASS定義的結(jié)構(gòu)體的頭部都有一個指向真實虛表結(jié)構(gòu)的指針。每一個STATIC 宏的頭部都有一個指向真實析構(gòu)函數(shù)的函數(shù)指針，以及一個用于實例計數(shù)的成員變量。通過DELETE宏進行析構(gòu)時，即調(diào)用圖7中＿＿ooc＿classDelete指針指向的函數(shù)。而用于計數(shù)的變量保證了使用者無需關(guān)注虛表結(jié)構(gòu)的構(gòu)造與析構(gòu)，當(dāng)一個類的第一實例構(gòu)造之前，該類的虛表結(jié)構(gòu)已經(jīng)自動構(gòu)造完成了；而當(dāng)一個類的最后一個實例銷毀后，該類的虛表結(jié)構(gòu)的析構(gòu)函數(shù)也會被自動調(diào)用。

從圖5可以看出，STATIC宏應(yīng)在CLASS宏后的大括號內(nèi)使用。其不僅引入了虛表結(jié)構(gòu)的頭部，還引入了實例結(jié)構(gòu)的尾部結(jié)構(gòu)。繼承關(guān)系每加深一級，會在實例結(jié)構(gòu)的尾部多分配一個雙重泛型指針，用于指向當(dāng)前類型的虛表結(jié)構(gòu)。而實例結(jié)構(gòu)頭部中虛表指針指向的是最后一級類型的虛表結(jié)構(gòu)。之所以這里采用雙重泛型指針，是為了保證在構(gòu)造與析構(gòu)時可以直接通過實例的構(gòu)造或析構(gòu)函數(shù)去修改位于虛表結(jié)構(gòu)中的用于實例計數(shù)的成員，同時這樣的設(shè)計可以保證宏的靈活性，不會引入額外的全局變量。

和CLASS 宏以及STATIC 宏不同，支持繼承的宏CLASS＿EX 以及STATIC＿EX 并不會再次引入實例結(jié)構(gòu)與虛表結(jié)構(gòu)的頭部。

3.3 構(gòu)造與析構(gòu)的設(shè)計

假定要頂一個名為A的類，在使用CLASS和STATIC來定義的時候，在底層定義了名為A和StA的結(jié)構(gòu)體，以及用于分配內(nèi)存的newA 函數(shù)以及newStA 函數(shù)，用于釋放內(nèi)存的delA 函數(shù)以及delStA 函數(shù)，用于構(gòu)造的iniA 函數(shù)以及iniStA 函數(shù)，用于析構(gòu)的finA 函數(shù)以及finStA 函數(shù)。在生成與銷毀一個實例時，和虛表結(jié)構(gòu)相關(guān)的newStA 函數(shù)，delStA 函數(shù)，iniStA 函數(shù)以及finStA 函數(shù)會被自動的調(diào)用。而ASM 宏則用來將用戶自己定義的A＿reload 函數(shù)，A＿unload 函數(shù)，A＿reloadSt函數(shù)以及A＿unloadSt函數(shù)與上述的幾個函數(shù)進行綁定。

以圖5中實例B的構(gòu)造與析構(gòu)為例，先使用NEW0宏在堆內(nèi)存聲明一個類B的實例，最后又用DELETE0宏將其銷毀并釋放，期間并沒有其它實例的分配與銷毀。在B的實例聲明和銷毀時，其會按圖8中所示的順序調(diào)用一些構(gòu)造和析構(gòu)相關(guān)的函數(shù)。

構(gòu)造時，第1，2步完成B的虛表結(jié)構(gòu)的構(gòu)造，第3步完成A的虛表結(jié)構(gòu)的構(gòu)造，第4，5步完成B的實例結(jié)構(gòu)的構(gòu)造。而析構(gòu)時，第1，2步完成B的實例結(jié)構(gòu)的析構(gòu)，第3步完成A的虛表結(jié)構(gòu)的析構(gòu)，第4，5步完成B的虛表結(jié)構(gòu)的析構(gòu)。

圖8 構(gòu)造與析構(gòu)的順序

可以看出，構(gòu)造和析構(gòu)的順序是完全對稱的，并且子類的構(gòu)造和析構(gòu)會自動調(diào)用父類的構(gòu)造和析構(gòu)，同時，虛表結(jié)構(gòu)的分配與銷毀也是自動的。而這些都是由ASM 宏和ASM＿EX 宏保證的。

當(dāng)定義的類或聲明的實例更加復(fù)雜時，為了減少記憶的負擔(dān)，其也應(yīng)具備對稱性。ASM 宏和ASM＿EX 宏保證了其構(gòu)造與析構(gòu)過程遵循如下算法。

構(gòu)造時，其遵循圖9 中的算法。而析構(gòu)時，其遵循圖10中的算法。

3.4 調(diào)試層的設(shè)計

為了方便調(diào)試，OOC－GCC項目中增加了方便調(diào)試程序調(diào)試層，可配合GCC（GNU compiler collection）一起使用。在將調(diào)試層一同編譯時，其會替換NEW 宏中封裝的malloc函數(shù)以及DELETE宏中封裝的free函數(shù)，進而可以對內(nèi)存的分配和釋放以記錄并輸出。如果輸出至文件，還配合Graphviz等工具方便的生成函數(shù)調(diào)用圖表。除此之外，OOC－GCC的調(diào)試層還對C＋＋的異常捕獲機制進行了簡單的模擬并提供了運行時間監(jiān)測等實用的功能。

OOC－GCC中關(guān)于類的設(shè)計和實現(xiàn)的宏在設(shè)計上嚴格的對稱，并沒有引入任何一個全局變量，符合C 語言模塊化的設(shè)計原則。也因此，其對調(diào)試層沒有任何依賴。如果某些編譯器不支持調(diào)試層提供的一些功能或是需要發(fā)布程序時，只需移除OODbg模塊，使其不參與編譯即可。

4 與C＋＋的對比

為了方便和C＋＋進行比較，須設(shè)計一個場景。

假定現(xiàn)有一個抽象的名為Animal的父類，其包含一個名為name的成員和一個名為talk的方法。另有兩個名為Cat和Dog的子類繼承了Animal這一父類，并各自重寫了父類中定義的talk方法（或重寫了父類中已經(jīng)實現(xiàn)的talk方法）。

在實際測試的例子中，通過子類來分配內(nèi)存，使用父類的形式來調(diào)用接口來調(diào)用以體現(xiàn)面向?qū)ο笏枷胫械亩鄳B(tài)的特性。一開始，直接在堆內(nèi)存上分配4000個子類的實例（Cat類和Dog類隨機），然后分別調(diào)用其talk方法，最后再依次將其析構(gòu)。

實際測試時的C代碼以及C＋＋代碼分別如圖11和圖12所示。

通過對圖11和圖12的對比可知，實際的代碼長度十分相近。僅僅是需要額外的聲明一個名為StAnimal的實例，并通過ST 宏獲取相應(yīng)的虛表結(jié)構(gòu)。

在ubuntu和windows xp系統(tǒng)上測試的關(guān)于生成程序體積的數(shù)據(jù)如表2所示（其中數(shù)據(jù)的單位為字節(jié)）。

表2 生成體積對比

可以看出，從生成代碼體積方面來說，其和使用C＋＋生成的代碼會有些差異，但這些差異并不顯著，并且在開啟優(yōu)化選項后，生成的體積有可能比原生的C＋＋占用更小的空間。

5 實際的應(yīng)用

表1中聲明的宏被設(shè)計成跨平臺的，不但支持開源的GCC編譯器，也兼容微軟的MSVC編譯器。對于容量受限或是開發(fā)工具受限的嵌入式平臺，即使無法很好的支持C＋＋等面向?qū)ο蟮木幊陶Z言，也可使用該模型可以大幅提升程序的可讀性和可維護性。實際測試中，AVR，STM32，MSP430 等芯片所使用的編譯器都可以很好的支持。

另外，利用OOC－GCC 項目中設(shè)計的對象模型，還可較為方便的將現(xiàn)有的使用面向?qū)ο笳Z言（如C＋＋，Java，Python等）編寫的代碼移植至純C 語言的平臺，文獻［9］中給出了一個用Java語言實現(xiàn)的簡易解釋器的例子，并且該解釋器的實現(xiàn)符合設(shè)計模式中解釋器模式［10］的規(guī)范。

假定要實現(xiàn)一個具備如下功能的解釋器：可以根據(jù)指定的格式向某終端輸出指定格式的字符串，并支持循環(huán)結(jié)構(gòu)。

圖13 解釋器的示例與運行結(jié)果

圖13中左側(cè)為該解釋器的示例代碼，右側(cè)為對應(yīng)的正確輸出。該例子中共有7個關(guān)鍵字。其中PROGRAM 表示程序的開始，與之對應(yīng)的END 既可用于程序的終結(jié)，也可用于循環(huán)結(jié)構(gòu)的終結(jié)，而循環(huán)結(jié)構(gòu)用REPEAT 關(guān)鍵字來描述，其后緊跟一個數(shù)字，用來指示具體循環(huán)的次數(shù)。PRINT 用于輸出指定的字符串，但由于涉及字符的轉(zhuǎn)義，這里使用SPACE關(guān)鍵字來輸出空格，并使用BREAK 關(guān)鍵字來輸出換行，而LINEBREAK 關(guān)鍵字則在輸出一行直線的同時額外的輸出一個換行。

將上述描述，可得出該解釋器定義的BNF范式，具體如圖14所示。

圖14 解釋器的BNF

在以解釋器模式進行設(shè)計時，BNF范式中的每一個節(jié)點都對應(yīng)一個類，而每個類都應(yīng)實現(xiàn)一個用于解析代碼并生成需要的AST 樹的接口以及一個對已生成的AST 樹進行遍歷并執(zhí)行接口。如圖14 所示，該范式由program，command list等5個關(guān)鍵節(jié)點構(gòu)成，按照解釋器模式的規(guī)定，需為這5個節(jié)點分別設(shè)計具備用來解析字符串和用來執(zhí)行抽象語法樹中定義規(guī)則的方法的類。

圖15 Repeat節(jié)點C實現(xiàn)

圖15中展示了使用OOC－GCC配合C 語言以實現(xiàn)用于循環(huán)控制的Repeat節(jié)點的方式，可以看到，配合OOCGCC，C語言在形式上已經(jīng)有明顯的面向?qū)ο蟮纳省Ｒ驗樵摾虞^為復(fù)雜，完整的實現(xiàn)可從文獻該例子較為復(fù)雜，完整的例子可參見文獻［5］中獲得。另外，在文獻［9］中給出了該解釋器分別以JAVA 語言以及Python語言實現(xiàn)的方法。通過對比可以看出，使用Java語言或Python等原生支持面向?qū)ο笏枷氲木幊陶Z言所編寫的代碼在邏輯上可以和使用C語言編寫的具備OO 風(fēng)格的代碼一一對應(yīng)，但因為缺乏諸如GC（garbage collector）等特性，在代碼量上，使用C語言編寫的程序仍比使用Java等語言編寫的程序要長一些。

6 結(jié)束語

利用現(xiàn)代C編譯器的特性以及元編程技巧，配合適用于C語言的對象模型，可以很好的利用面向?qū)ο蟮乃枷?，提升C程序的可重用性。OOC－GCC中的設(shè)計，通過宏的方式簡化因引入面向?qū)ο笏枷攵a(chǎn)生的附加代碼，無需借助任何第三方代碼生成工具，很好的將OOP 與C 語言像結(jié)合。同時，其靈活的設(shè)計，維持了和C＋＋相似的編碼風(fēng)格，符合C語言模塊化［11］的編碼規(guī)范，不依賴于其它第三方庫，在實際中可以很好的解決大規(guī)模C 代碼難以復(fù)用，難以管理的問題。

相較于著名的GObject庫，這是一種輕量級的實現(xiàn)，并沒有提供復(fù)雜的對象系統(tǒng)，但更加靈活易用，且方便移植。如果需要對象系統(tǒng)的支持，也可配合GObject，Lua，Python［12］以及Ruby中的對象系統(tǒng)一起使用。

為了方便測試以及推廣文中涉及的代碼。OOC－GCC項目遵循LGPL 3.0開源協(xié)議托管于Google Code，文獻［5］中給出了具體的鏈接，可供讀者測試，驗證和使用。

［1］Bjarne Stroustrup.Evolving a language in and for the real world：C＋＋1991－2006［C］／／HOPL III，Proceedings of the Third ACM SIGPLAN Conference on History of Programming Languages，2007：3－5.

［2］Bjarne Stroustrup.The Design and evolution of C＋＋［M］.QIU Zongyan，transl.China Machine Press，2002：7－37（in Chinese）.［Bjarne Stroustrup.C＋＋語言的設(shè)計和演化［M］.裘宗燕，譯.機械工業(yè)出版社，2002：3－37.］

［3］ANSI C89Standard，ANSI X3.159－1989［S］.

［4］ISO C99Standard，ISO／IEC 9899：1990［S］.

［5］MENG Fanchao.OOC－GCC project：An easy to use template to write OO program with pure C programming language［CP／OL］.http：／／code.google.com／p／ooc－gcc／，2012（in Chinese）.［孟繁超.OOC－GCC［CP／OL］.http：／／code.google.com／p／oocgcc／，2012.］

［6］Stanley B Lippman.Inside The C＋＋object model［M］.HOU Jie，transl.Publishing House of Electronics Industry，2012：1－13（in Chinese）.［Stanley B Lippman.深度探索C＋＋對象模型［M］.侯捷，譯.電子工業(yè)出版社，2012：1－13.］

［7］Andrew Krause.Foundations of GTK＋development［M］.Apress?，2007：406－456.

［8］SONG Guowei.GTK ＋2.0 programming paradigm［M］.Tsinghua University Press，2002：174－178（in Chinese）.［宋國偉：GTK＋2.0 編程范例［M］.清華大學(xué)出版社，2002：174－178］

［9］LIN Xinliang.Notes about design interpreter pattern［J／OL］.http：／／caterpillar.onlyfun.net／Gossip／DesignPattern／InterpreterPattern.htm，2010（in Chinese）.［林信良.關(guān)于解釋器模式的筆記［J／OL］.http：／／caterpillar.onlyfun.net／Gossip／DesignPattern／InterpreterPattern.htm，2010.］

［10］Erich Gamma，Richard Helm，Ralph Johnson，et al.Design patterns：Elements of reusable object－oriented software［M］.Addison－Wesley Professional，1995：274－288

［11］David R Hanson.C interfaces and implementations：Techniques for creating reusable software［M］.GUO Xu，transl.Posts ＆Telecom Press，2011：1－21（in Chinese）.［David R Hanson.C語言接口與實現(xiàn)：創(chuàng)建可重用軟件的技術(shù)［M］.郭旭，譯.人民郵電出版社，2011：1－21］

［12］CHEN Ru.Inside python source code：dig into the core of the dynamic languages［M］.Publishing House of Electronics Industry，2008：15－28（in Chinese）.［陳儒.Python 源碼剖析：深度探索動態(tài)語言核心技術(shù)［M］.電子工業(yè)出版社，2008：15－28.］