先聲明一個概念，裸編程，我創造的名詞，指的是在裸機上編寫程序，裸機，在單片機領域就是指帶著
硬件的單片機控制系統，不要想歪咯。
在裸機上編程，就猶如在一片荒地上開墾，任何一鋤頭下去，都會碰到硬生生的石頭，要說做這有什么味？拓荒者追求的是來年的綠洲。而我們這些開墾裸機的所謂的工程師們追求的是什么？我們當然追求的是完成一個任務。
我們一般都自稱是高級知識分子，那么我們在拓荒的過程中應該想些什么？當然不是想著如何把任務完成，而應該首先想著我們在想些什么。繞了是不？繞了就對了，這一繞就繞出了思想。思想是一個簡單的人在一個復雜的環境里做任何事情的統帥，它影響著一個拓荒者人生的每一個細節，當然也包括裸編程本身。
當一個人拿著鋤頭，一鋤又一鋤，汗滴腳下土的時候，我們能知道他們在想什么嗎？當然這不好說，如果自己去鋤就知道了。但是大抵也差不多，隨便舉幾個吧：這太陽他娘的怎么這么毒？這石頭他娘的咋這么多？這地種什么最好？這還有多少天能搞完？這樣干太慢了，要是有臺機械搞多好。當然這只是一部分，任何人可以想出很多想法來。
那么當我們在裸機上拓荒的時候，我們該想些什么？也許我們一般的想法是：先把一個簡單的功能做了，先把一個重要的功能做了，今天終于把這個功能調試好了明天可以做下一個功能了，這個為什么不是我想象的那樣的結果？真是莫名其妙！也等等一下吧。
如果拿來一個任務，搭好測試平臺就開始做程序，想著一個功能一個功能的湊完，然后就自我陶醉著成功的喜悅，那這樣做程序，基本就叫做沒思想。有思想的做程序，是不能一下去就堆積源碼的，因為那樣只會讓一堆生硬的數字怯生生的擠在一起，不管他們有沒有多余，有沒有矛盾。所以寫源碼之前，是要想想如何寫的。也許很多人在寫之前都想過類似的問題，比如把任務模塊化后再組織程序。但是這樣的想法只是任務上的事情，而并不是裸編程時的思想，裸編程的思想，應該是在組織任務模塊過程中及編寫裸程序時影響源碼組織的指導思想，它直接決定著源碼的質量。
一個數據結構，一個模塊形成，一個單片機的指令，一個硬指令的運行機制，一個口線的驅動方式，一個中斷的順序，一個跳變的延遲，一個代碼的位置，一個邏輯的組織，一個模塊與模塊之間的生（運行時的狀態）死（不運行時的狀態）關系等等，都是裸程序思想的組成部分。
這似乎很瑣碎，但是裸程序原本就如此，它不同于上位機程序，有一個強大完善的操作系統支持。單片機里不可能植入操作系統，那樣做就變味了，可不要有人跳出來說，某某某單片機就有操作系統了。裸程序就應該是建立在赤裸裸的硬件基礎上的程序，只有有用的功能才有代碼，裸程序的質量也許經常在應用中感覺不出來，也許你做和他做都能實現功能，但是好的裸程序有良好的可擴充性、可維護性，系統具有高穩定性和高性能。
而追求這種高品位的技術境界，就必須要有好的思想來指導。是不是看著有些迷糊？別說看得迷糊，我說都說迷糊了，總的來說，就是把一個優秀的靈魂，植入你的源碼中，讓你的源碼具有一個優良的思想。
網友評論：其實，在組織顯示屏幕和菜單時，使用面向對象的思想也是很不錯的想法。我就是從這里開始的。避免在程序中出現大量switch套switch的情況.但是，有一個問題，抽象度越高，層次約多，浪費的物理資源就越多。所以，感激還要根據實際情況，組織程序。
網友評論：唉，論壇里高手真多，以后不要亂吹牛，免得恰到喉嚨........
占座位學習，期待父對象的重要意義。。。。。。
我怎么覺得LZ是在講C++的理念多一些呢
網友評論：面向對象裸程序的例子≡
顯示器控制程序[連載六]
上帖我們說到dispGetMaxColors()的一些設計思路，我們有很多很好的辦法來實現它，但是我們有沒有更好的管理辦法來實現它，這才是我們要站在更高層次看問題的焦點，是更重要的。這也就是一個從傳統思維到面向對象思維的一個重要的轉折。
要想把這個函數轉變為面向對象的邏輯結構，我們也要先做些準備工作。
首先說參數傳遞的思想。盡量減少參數傳遞，這是尊重C51系列8位單片機硬件現狀的一項重要措施，記著，不要抱怨C51檔次低，資源少，而是要在尊重和熱愛C51的前提下，我們才有熱情來發展我們的裸程序面向對象思想的，也就是說，無論我們面臨的系統有多簡陋，我們都有策略，來實現復雜的功能，而且從發展的眼光來看，產品的升級，并不是盲目的升級我的CPU，因為那樣只會讓產品設計者智商下降，所以我覺得C51的特色就是應該在簡潔，越來越簡潔，而不是越來越復雜。所以我希望我們把思想升級作為升級產品的一個發展方向。傳遞參數要減少指針、浮點等類型的數據傳遞，盡量以UCH與UINT為主，而且參數的數量不要太多，最理想的上限是2個，如果實在多了，就使用共享緩沖區，或者全局變量。最好是不要傳遞參數，呵呵。
本函數就利用了MonitorType省略了一個參數傳遞。
其次是我們要讓父對象的接口函數與具體的子對象的多種可能性的功能實現剝離，這里我們就需要使用函數指針。函數指針也許我們一般用得少，但是其實并不是很復雜。先看我們函數的形式：
UINT dispGetMaxColors(void);
為該函數定義一個指針類型，只需做如下定義，就可以了：
typedef UINT (*dGMC)(void);
那么對于父對象中的dispGetMaxColors()函數，我們就只需要轉換定義一個函數指針，在創建父對象的時候為它提供一個子對象對應功能調用的入口地址，就足夠了。所以對于這個函數的實體將只在子對象中出現，而在父對象中只會出現一個變量的定義：
dGMCdispGetMaxColors;
為了給它賦初值，我們也可以定義一個空指針，作為一個未使用的判斷標志：
#define NIL 0
那么初始化dispGetMaxColors的時候只需要寫條如下語句就可以了：
dispGetMaxColors = NIL;
而且功能調用也很簡單，與實質的函數是一樣的：
if(dispGetMaxColors!=NIL) vMaxColors = dispGetMaxColors();
如果再加上約定，連前面的判斷語句完全可以省略。因為我們的裸程序的程序空間實際上也是運行空間，不存在代碼調入
內存和移出內存的事情發生，所以我們不需要考慮程序內存的優化問題，只要我們規定對象一定是先創建后使用，判斷語句就會變得沒有意義，而且我們創建后即使不再使用，函數體我們也不會釋放，因為它被放在程序空間內是固定死的，你想移出去，還不能實現呢。
第三，盡量讓程序所使用的語法簡單化，以減少編譯器可能帶來的差別而產生的理解上的誤區。有人說C51是C的子集，這說法我認為不科學，只能說二者繼承了C的基本精神，而在實質上它們針對的是不同的對象，所以也出現了一些不同的結果，所以我看到有些高手或者一些面試題弄出一些題目來讓我望而生畏，也許我做一輩子的裸程序也做不出他們的題目，但是我并不覺得我不如他們。他們只不過是在編譯器上花了很多時間研究他們的一些約定，而我并不想花時間去研究那些將來可能發生變化的東西，我希望我能用一個更簡單的途徑把我的事情做出色，我只關心我的項目的速度、代碼的大小、運行的效率、維護的復雜度，所以我也建議和我交流的人能用一種通俗的方法來實現我們的功能，也不必過多的考慮我的程序在8位單片機上可以用16位單片機上也可以用，我們的系統要經常升級，但不要輕易去增加硬件成本。當然如果你有精力去研究那些約定，也沒什么，只要你樂意。
好了，上面三條，只有第二條是我要說的關鍵，其他兩條各人可以根據自己的具體情況來尋找一些快捷實用的方法。其實說來我們把父對象用函數指針來代替實體函數，這完全是一種思想，我們并沒有使用復雜的語法，而是從管理上把對象分離開來，讓不同的人做不同的事情，比較容易。但是同時我們又不能讓這種中間環節影響我們程序的效率，所以我們完全可以自己尋求一些方法，而不必去循規蹈矩。我這樣說也許會遭到一些非議，但是我可以告訴大家，
計算機語言這門學科，本身就是一門人造科學，沒有最好只有更好，我們沒必要完全按照別人的思路去發展設計思想，所以也不要拿著人家的一些約定來引以為榮，那些東西，只有先學后學的問題，沒有水平的差異；我們應該更注意的是，人家創造了
工具，我們就用工具再來創造世界！如果你停留在欣賞工具的層次上，那就是無所鳥事了！
本帖實質上只說了一個轉換，兩條建議，這都不是具體的程序，而是思想。我想強調的，也不是格式，而是思想。下帖將再回到對象上，和大家探討一下對象本身的組織問題，比如對象的層次關系、對象的創建、對象的書寫等等，我也希望有人能有一些更好的方法回到帖子里，我們互相學習，共同提高。
網友評論：好!看完了,還是有點模糊!
太概能理解那種思想了
網友評論：
面向對象裸程序的例子≡顯示器控制程序[連載七]
前面的思想衍變過程已經說了很久了，面向對象的思想也就到了瓜熟蒂落呼之欲出的境界了。下面我就先圖示一下裸程序設計中面向對象思想的層次關系：
[img][/img]
相信這張圖已經足夠說清楚我們在Keil C中如何用語言來組織我們的顯示器對象disp了。disp是一個抽象的對象，它只是一種聯系，完成對所有子對象d000、d001、d002到最多d255的歸納概括并提供一組被調用者所使用的功能接口。這些功能接口正是上貼所提到的函數指針。而具體的功能實現及不同顯示對象對數據結構的要求，我們都可以交給子對象設計工程師自己去決定。
很顯然，大家在這套方案具體的程序設計過程中，最主要的精力還是要放在自己做自己的問題上，多思考如何把事情做得更漂亮，而不必在代碼編寫時黏糊不清。父對象設計者必須要完成總體方案的設計，抽象思維多而具體工作量少，子對象的設計者則恰恰相反，只需要多考慮考慮具體的設計，而不必去擔心別人是怎么用自己的東西。
很顯然，作為總體設計者，必須要嚴格考慮這中間的數據交換關系，因為我們沒有操作系統，所以對于可用的內存資源的使用法則，直接關系到我們整個系統的成敗，混亂使用常常會導致系統崩潰，相對獨立的代碼則在編譯過程中由Keil C直接安排好了，我們不需要去考慮它們對程序的影響。
例子中的顯存大小及顯存的位置都是我們方案成敗的關鍵。我們都知道Keil C對單片機內存劃分了四種，即data、idata、pdata、xdata四種，各種存儲器的大小與特點都決定著我們代碼的運行效果，我們既要考慮信息所需要的空間，又要考慮單片機處理時足夠達到我們的視覺要求。在這個例子中，我覺得我們可以選擇xdata來作為顯存。為什么呢？因為我覺得只要我們處理得當，我們的單片機完全可以克服處理速度上的缺陷，所以我們可以優先滿足信息量的要求，提供足夠多的空間來實現我們想要的功能。
提速的方式有很多，比如：選擇一些性能優越的新型單片機，傳統的是12T的，現在有6T的，也有1T的，這讓很多指令都會有更高的效率；適當的提高晶振頻率；選擇更科學的算法；等等。
好了，本帖先到這里吧，又覺得寫多了。到目前為止，基本上可以去構造我們的對象了，如果你有興趣，你可以使用#define進行一些偽碼定義，把我們的對象定義得更美觀一點，更接近C++一些，不過我要說的是：我們這里沒有嚴格的類定義，所以定義時類與對象經常是沒有界限的。
網友評論：面向對象裸程序的例子≡顯示器控制程序[連載八]
用基本C來構造一個對象，我們必須要多摸索摸索，因為沒有語法支持。但是我們不必抱怨，因為有些支持，C編譯器做和我們做，效果都是差不多的。
構造對象我們首先要遵循數據與函數分開的原則，這樣對我們創建新對象很有好處。也就是說我們把對象中的函數，都要寫到與具體數據無關，那樣當我們需要2個或2個以上對象時，我們只需要把數據重新復制一份，而具體的處理代碼卻不必重新寫，這樣我們就可以爭取用最少的代碼而獲得最多的功能。
我很怕羅嗦的語法結構，所以我在上帖中希望有人能回我的帖，把上面的例子用語法總結出來，很遺憾卻沒有，我想偷懶都不成，所以只好把原來的帖子一個一個的翻出來再讀。寫說與偽指令相關的事情。看下面的例子：
#define Class(c) struct c
#define Object(o,c) struct c o
這兩個偽碼就會把我們的裸程序搞得挺象個C++的樣子，其實也就是欺騙一下看官的眼球而已，如果你不屑一做，那就直接用struct也滿好個。有了這兩個定義，我們就把前面例子羅列一下，形成一個對象的樣子來。
還有幾個函數指針類型我們都把它們定義出來（下面定義忽略了參數定義）：
typedefvoid(*dSAC)(……); // 顯示一個字符指針類型
typedefvoid(*dSAL)(……); // 顯示一行指針類型
再定義類：
Class(disp)
{
UCHMonitorType; // 數據變量定義
:
:
:
dSAC dispShowAChar; // 功能變量定義
dSAL dispShowALine;
:
:
:
};
相信這樣已經足夠說明問題了，這個類就是定義了一個對象所需要的全部數據，凡是涉及到代碼的都可以作為同一類型的不同對象共有的財富，共同使用。比如我們要在我們的裸系統中企圖同時支持最多兩個顯示器，那么我們就只需要創建兩個對象，其實這里說的創建語法也很簡單，就說定義兩個變量好了，然后賦初始值給它，這就是創建。
先定義：
Object(FD000, disp); // 定義對象FD000，關聯子對象D000
Object(FD001, disp); // 定義對象FD001，關聯子對象D001
然后通過賦予初始值來創建它，這里再引入一個偽定義：
#defineCreateObject (o, mt, sac, sal){ \\
##o.MonitorType = mt; \\
##o.dispShowAChar = sac; \\
##o.dispShowALine = sal;}
這樣我們就可以象模象樣地使用我們的對象了：
CreateObject(FD000,0,soShowAChar000,soShowAChar000,soShowALine000);
這條語句創建了一個缺省顯示器的父對象，其中so-是sub object的縮寫，000是為編號為0的缺省顯示器所安排的編號，最后一個是255，因為Monitor是UCH類型，所以最多可以建立255個類型的顯示器。soShowAChar000、soShowALine000為缺省類型的顯示器的具體處理函數的名字，函數體在子對象D000中去組織。
同樣的方法我們為我們的裸程序創建另一個對象：
CreateObject(FD001,1,soShowAChar001,soShowAChar001,soShowALine001);
當然這個CreateObject只是一個例子，因為我們這個創建工作可能會有很長的參數，那么有豐富編程經驗的高手，您是愿意如何組織您的創建過程呢？我想我沒有必要在我的思想里去弄一個嚴謹的格式，思路是沒有清晰路線的，它具有很大的延展性，只要能勝任“合理”這個詞，您就可以大膽的去做。
本帖的最后我想提出一個問題：MonitorType將何去何從？
網友評論：面向對象裸程序的例子≡顯示器控制程序[連載九]
上帖說到的對于對象在Keil C中的一些構造，用到了一些#define所進行的一些偽定義，這些定義其實并沒有多少真正的意義，唯一的意義就是讓我們的語言看起來更象個面向對象的語言。
面向對象的語言中，變量或函數的作用域分成三類：public、private、protect。這分類主要是處理語言模塊的封裝問題，其直接表現的效果就是變量或函數能使用的范圍。protect類型在我們這里可以不予考慮，因為我們并不十分強調繼承關系，而只是統一都稱為一種文檔的組織關系#include。
而對于public與private則還是有比較方便的辦法實現的。對于public，我們可以使用extern來進行定義，或者什么定義都不帶，在#include后面的范圍內都是有效的。所以要定義一個public非常容易，只要做下列定義就可以了：
#definepublic
或者
#definepublicextern
就可以了。
對于作用域的限制，還有一個重要的限制就是哪些變量用什么辦法約束起來，從而成為一個屬主的私有成員。
當然，這樣的約束，寫在一起，是個好辦法。說實在的，只要你有足夠的精力，即使不寫在一起，只要不搞錯，又有何不可？只是我們為了減少不必要的麻煩，所以我們總希望我們的代碼只花我們盡量少的精力，那才是最理想的，那么我們就肯定要首先要求把它們寫在一起，然后我們還希望它們不僅僅是只在一起，還希望編譯器真正認為它們是被我們創建的某個對象私有的，那么我們就可以使用static來進行約束。全局靜態變量或函數的定義，可以將該變量或函數的作用域限制在本文檔內部，這就是一種私有性。因為我們完全可以做到在一個文檔中只書寫一個對象。因此我們就可以如定義public一樣來定義 private：
#defineprivatestatic
那么這樣我們就可以為對象書寫一些私有成員，如：
privateUCHsoCursorPositionRow000 = 0;
privatevoidsoSetCursorPosition000(void);
如果我們并不想用這么多的private來限制這些成員，那么偽限制也是一種好辦法，也就是說只是在書寫格式上告訴看官，我的這段定義是私有成員，那么我們可以做如下的修改：
#defineprivate
#definepublic
private
UCHsoCursorPositionRow000 = 0;
voidsoSetCursorPosition000(void);
public
voidsoShowAChar000(void);
voidsoShowALine000(void);
這樣寫沒有定義任何變量的作用域，而只是為代碼加上了一些欺騙眼球的偽碼，這樣做其實對程序實質沒有任何幫助，但是得益的是我們程序設計的思想。也許我們只用了一兩個很簡練的偽碼，卻表達了很深奧很深奧的邏輯寓意——這是一段表達對象的代碼，你不用做任何注解就明了的代碼。這其實也正是思想的精髓所在，你把一團亂麻理順了，你把一盤散沙促攏了。
表達對象思想的書寫中，封裝是一個很重要的組織概念，封在一起的是一個整體，就如人家端個顯示器給你一樣，你不要管里頭的電子束是怎么射出來的，一共有幾顆螺絲釘固定著顯象管，你所要關注的，只是那些接頭和按鈕。
static在封裝中還可以起另一個作用，就是為某一個功能封裝一個隸屬于該功能的局部變量，你可以對該變量進行初始化，但是你在實際應用中你不能感覺到它的存在，它的生命周期是無期的，但是擁有它的函數卻可以生死輪回。下面是一個調節亮度的例子：
#defineBRIGHTINC1
#defineBRIGHTDEC0
voidsoAdjustBright000To(bitBrightInc)
{
staticUCHBright = 32;// 初始化：最大亮度為64，初始化亮度為32
if(BrightInc)
{// 亮度增加
if(Bright<64)Bright++;
}
else
{//亮度減少
if(Bright)Bright--;
}
}
網友評論：寫得好!
網友評論：看不懂,先做做記號,等懂了,再給你回個話.
網友評論：很棒哦，還有原創性，支持啊！
網友評論：我感覺很抱歉的是,此帖以后添加的速度將會減緩,一個是工作上有時候會要忙,另外是正準備把這個思想系統成書,對本帖的思想進行更正規的描述,旨在喚起我們追求技術的熱情,引導更多的人用正確的方向來指導我們獲得更多的成功,在此過程中,我會逐漸添加一些新的內容,也希望廣大同仁與我一起探討問題,謝謝大家的關注,非常感謝!
網友評論：關注下
網友評論：再寫一點可以出書了，呵呵~
網友評論：
好帖！這樣思路上的指導遠比具體的實踐指導更有實際意義。
知其然不知其所以然是很多人的毛病，會用就行了，自我滿足了，而不去追根求底不去想怎樣能把事情做到更好。
我一直覺得大道不傳是因為傳不了，因為大道理是很難用語言來表述清楚的。我們的語言有時候是那么的蒼白無力，交流上的匱乏使我們民族有太多的優秀文化思想無法流傳下去。
樓主的帖子不僅僅能應用在單片機開發設計上，更可以廣泛的應用在日常的生活中、我們處理生活事物當中去。
從裸程序開發說出去，擴展開，是本文的一個特色，更是千古豐碑的一篇文章。
看到這樣好的文章，我實在不甘心放棄一個簽名的機會。同時也希望樓主不要辜負大家的期望繼續更新下去。
最后問一句，下一章啥時候出？您快點啊，大伙都等的特著急啊，不趕緊更新對不起黨和人民還有21IC廣大的網友啊~~~啊~~~
網友評論：又學習了 多謝 多謝
網友評論：
裸編程的思想，應該是在組織任務模塊過程中及編寫裸程序時影響源碼組織的指導思想
不曉得和模塊化編程有啥子區別？
面向對象只是聽說過，還沒用過，還是有點看不懂
網友評論：寫得好，不過好多地方不明白，平常一直覺得有點意思的就是用結構體封裝，似乎有那么一點面向對象的意思，但是在分析任務時，頭腦里全是面向過程的，新手之言，請砸磚
網友評論：最近工作上忙著改產品，所以沒時間來忽悠，不過我會經常來關注一下朋友們的回帖，然后致力寫一本系統性的書，盡量增加思路分析的例子，并增加例子的代表性與廣泛性，力求讓大家都能輕易看懂，如看小說一樣的具有可讀性，謝謝朋友們的支持
網友評論：陽春白雪和著蓋寡。
問：先生是做什么的？
答：玩單片機的。
問：單片機--------什么玩藝兒？
答：是玩思想。
問：-------------？？
網友評論：做個記號！回頭來學習！
網友評論：好好學習天天向上
網友評論：寫的好
網友評論：支持，頂...
網友評論：先頂后看
呵呵
網友評論：怎么沒啦！呵呵！學習學習，現在正好可以用上這種思想中的一點點！還不會用
網友評論：要用就用Ｃ＋＋好了，單片機沒有Ｃ＋＋的就用ＡＲＭ好了。
網友評論：隨著單片機性能越來越高，編程思想也在轉變。
話說，為了通用，必然要犧牲性能
網友評論：跟高煥堂寫的oopc意思差不多。
網友評論：頂！繼續
網友評論：很瑣碎的說
網友評論：很有思想。
網友評論：看了一次不是很清楚，再看看
網友評論：c++，最近在看。。
網友評論：這中思想正是我追求的，支持~
1#
網友評論：占位
網友評論：收藏啦
網友評論：頂。。學習中。。。
網友評論：可以借助面向對象的思想
網友評論：聽課，學習中。
網友評論：聽課
網友評論：沒有c++,樓主在c語言上像三腳貓一樣跳舞.
建議大家用c++去學習,然后回到c語言中體會如何實現.
這些東西在軟件工程和構架里面的基礎.學計算機的都很懂.
剛完成一個10多人年的項目.
網友評論：占個位，好好看看！
網友評論：來看看，
網友評論：占個座
網友評論：有此等高人為后輩鋪路，實乃幸事也！
網友評論：學習。
網友評論：頂一下
網友評論：好貼，頂一下！
網友評論：經驗之談，頂！
網友評論：頂 頂 頂頂頂
網友評論：讀了，思考一下，想一下，消化一下，轉化一下。
網友評論：有黨的風范
網友評論：自我陶醉吧
網友評論：沒有c++,樓主在c語言上像三腳貓一樣跳舞.
建議大家用c++去學習,然后回到c語言中體會如何實現.
這些東西在軟件工程和構架里面的基礎.學計算機的都很懂.
剛完成一個10多人年的項目. ...
icecut 發表于 2010-8-31 13:35
沒想到這個帖子還在活躍。C++盡管在思想上是一種成熟的技術，并配有編譯器的支持。但是C++同時還約束了自由行為思想。
你盡管懂了C++，但是不懂得中國現狀與開發心理。在C++里抽象對象比自由抽象對象要難得多，而且單片機是從**做起的，而C++就是一層濃霧，讓開發者常常迷失在這層霧中。
我這帖正是拋棄了這些語法約束，直接使用人人皆知的普通C語言，來達到同樣的目的，只需要轉換一下思想就可以了。最主要的是，這種做法更自由，開發者可以自己控制硬件資源的分配情況，而不必去學習更抽象的資源分配理論。
看你對C++比較熟悉，也做了大項目，這是好事，有高級語言的使用資本。但是這資本并沒什么好炫耀的，因為我相信懂C++的人一定很多，但是在單片機上用C++，我認為還不如用C，因為我覺得，把內存調度交給編譯器，不如控制在自己手中靈活。我也很少在帖子里去推崇C++，也是這個道理。而且我過去是做計算機軟件的，也從沒想過因為自己用過了面向對象語言就去貶基本語言，因為C++并非什么地方都適用！
謙虛是進步之本！你可以炫耀你的項目，但是不要炫耀C++，因為那根本與你沒什么關聯。
網友評論：強烈支持。
網友評論：嗯，81樓說得太好了，其實在寫代碼的時候，我們并不想知道模塊內部是怎么操作的，但是，在運行的時候，每一個地方每一個角落我們都想知道內部是怎么操作的，使系統完全掌握在自己手中。
網友評論：樓主太強大了，膜拜啊。。。
但是太多了，先復制下來，今后有空再慢慢看
網友評論：樓主人才。。頂起
網友評論：體會一下編程思想來了
網友評論：此貼必須要狂頂
俺先收錄了俺正在研究不知對俺有沒有好處 先收錄好東西不能錯過
再次頂作者
