kapok

維護(hù)頭文件通常是一個(gè)冗長乏味并且容易出錯(cuò)的過程，感謝.NET  assembly類庫抹去了對這些文件的倚賴。

微軟.NET的可管理的C++最終簡化了我們創(chuàng)建類庫的方法，或更準(zhǔn)確些，.NET assembly類庫，這種簡化得以實(shí)現(xiàn)主要是由于assembly類庫是可以自我描述的。這對一個(gè)Managed C++程序員意味著什么呢？基本上講，一旦 assembly編譯成功，你在編譯傳統(tǒng)C++類庫的時(shí)謹(jǐn)慎創(chuàng)建的所有頭文件除了維護(hù)的需要外，都不再是必需的。

就個(gè)人而言，我感覺維護(hù)頭文件是一種痛苦，所以我很高興看到這種對頭文件的倚賴正在消失。我經(jīng)常會忘記需要在庫中引用的一個(gè)或多個(gè)頭文件的名稱，為了找到缺失的數(shù)據(jù)類型定義，我不得不對所有含有頭文件的內(nèi)容進(jìn)行搜索，更糟糕的是，將源代碼拆分為兩半增加了我犯錯(cuò)誤的機(jī)會。我經(jīng)常犯的錯(cuò)誤包括忘記將所有的包含頭文件打包、使.h文件和.cpp脫離同步。

既然對頭文件的程序集不再是必需的，你可以使用一種改進(jìn)了的新方法來創(chuàng)建源文件。但在考察這種方法之前，先讓我們先來回顧一下創(chuàng)建程序集的傳統(tǒng)方法

傳統(tǒng)方法

在C++中，傳統(tǒng)的庫文件創(chuàng)建方法是建立一系列頭文件用以描述類庫中所有的功能；接下來，你要在一個(gè)單獨(dú)的源文件中實(shí)現(xiàn)這些頭文件所定義了的所有功能。然后，在編譯器中運(yùn)行每一個(gè)源代碼文件連同其相關(guān)的頭文件，以生成目標(biāo)文件；再將所有的目標(biāo)文件相互鏈接來創(chuàng)建庫文件

圖A描述了這種傳統(tǒng)方法。

圖A 

創(chuàng)建庫的傳統(tǒng)方法

使用頭文件的原因在于，今后引用這個(gè)類的時(shí)候，所有的類、結(jié)構(gòu)體、變量等等都可以很方便的定義。

程序集可以使用同樣的方法生成，這一過程的唯一區(qū)別在于Managed C++的標(biāo)志是事先確定的。

在下面的例子中，列表A、B、C和D演示了如何用傳統(tǒng)C++的方法創(chuàng)建一個(gè) assembly。

列表A給出了頭文件Cards.h的定義，這個(gè)文件定義了一個(gè)包含撲克牌和Card類的枚舉(enmu)，注意，使用ManagedC++時(shí)，關(guān)鍵字public要放在enum和class之前的，因?yàn)檫@兩者都需要在全局范圍內(nèi)可以被訪問。

列表B展示了類的構(gòu)造器和成員方法的實(shí)現(xiàn)，列表C定義了第二個(gè)類Deck，注意，雖然從來沒有在頭文件中定義，但Card類是在Deck類之內(nèi)使用的，使用這一技巧需要謹(jǐn)記：在編譯過程中，頭文件基本上是大批量地粘貼到源文件中的。既然是這樣的情況，我們只需簡單地在Deck.cpp源文件的包含文件列表中將Card.h放在Deck.h的前面，如此操作之后，Card類將首先被粘貼，繼而被定義為Deck類所必需的類。

列表D顯示了在這個(gè)迷你庫中的源文件，注意，正如我們剛剛所提到的，Card.h包含在Deck.h之前。

在命令行中執(zhí)行建立 assembly庫的命令并不像火箭科學(xué)一樣艱難，其語法（沒有這些省略號）非常簡單：

cl source1.cpp source2.cpp ... sourceN.cpp /CLR /LD /o OutputName.dll

C++編譯器取走這一系列源文件的名稱，然后是/CLR參數(shù)，它告訴編譯器我們正在使用managed的擴(kuò)展，繼而/LD參數(shù)告訴連接器去創(chuàng)建一個(gè).dll文件，最后/o參數(shù)將說明這個(gè).dll文件的名稱。

為了編譯以上的例子，你可能會用到這行命令：

clcard.cppdeck.cpp /CLR /LD /o cards.dll

新的 assembly方法

不再受困于分離頭文件和源文件的工作，就為新的庫文件編碼方式提供了可能性。在兜了一個(gè)圈子之后，我將開始介紹我的簡便方法，首先，將所有的類以類文件(.h)形式進(jìn)行編碼，其中包括所有的定義和實(shí)現(xiàn)；然后使用一個(gè)單獨(dú)的連接器文件(.cpp)來包含所有的類文件；這種方法唯一有些棘手的部分在于，你要確定所有的類文件是按照正確的順序排列的，以保證一切需要調(diào)用的數(shù)據(jù)類型在使用之前都已經(jīng)定義好了，即使使用傳統(tǒng)方法，這一問題同樣需要處理。圖B展示了這種新的 assembly方法。

圖B

新的 assembly方法

采用這種方法，你只需維護(hù)半數(shù)文件，既然定義和源碼是一同定義的，就不會造成不同步的。這樣一來，維護(hù)庫的工作就簡單了很多，另外，開發(fā)文檔只需保存在一個(gè)地方，也就更容易閱讀，所有這些都說說明了這是一種更好的方法。

列表E、F和G展示了使用新方法生成的同樣的庫。

正如你看到的那樣，列表E是傳統(tǒng)方法中Card.h和Card.cpp這兩個(gè)文件相結(jié)合而形成的，我基本上只是把實(shí)現(xiàn)部分直接放在類的定義中，而不是在一個(gè)單獨(dú)的文件中進(jìn)行定義。

同樣的，列表F是傳統(tǒng)方法中Deck.h和Deck.cpp這兩個(gè)文件相結(jié)合形成的，如果使用傳統(tǒng)方法，你可以在這個(gè)類中訪問其他的類而不必在文件中定義他們，連接器文件需要確保所有類的定義是按照正確的順序排列的，以保證這些類在使用之前都已經(jīng)定義好了。

在列表G中顯示的連接器文件是唯一一個(gè)與眾不同的文件，它除了包含語句之外沒有任何其他的東西，ManagedC++編譯器只編譯.cpp文件，為了讓編譯器完成所有的工作，你必須有這個(gè)文件。這種便利所帶來的副作用是從庫中添加或刪除類變得容易了，而你已經(jīng)將組成庫的類名稱記錄在了一個(gè)單一的地方。在開發(fā)過程中，連接器文件還是一個(gè)放置測試代碼的理想場所。

以這種方法建立一個(gè)assembly類庫的額外的優(yōu)點(diǎn)是，在命令行條件下使用時(shí)，其命令很簡單：

clcards.cpp /CLR /LD

結(jié)論

具有自我描述功能的 assembly器簡化了我們編碼的方法，這主要是因?yàn)樵创a模塊不再需要被分離為頭文件和源碼文件，正因?yàn)榈靡嬗诖耍覀冋故玖艘环N構(gòu)造 assembly庫的新方法。