提高民眾辨別是非的素質，始終被認為是很重要的。“有關部門”時刻提醒我們要廣泛學習，要能夠識別假幣；能夠通過外包裝和IMEI串號等方式，辨認假冒偽劣商品，包括水貨；要能分辨虛假廣告，要具備一定的科學知識，對有毒的食品添加物能夠正確判斷，包括蘇丹紅、孔雀綠，以及像甲醛和苯類化合物；要冷靜分析，不要被一些居心叵測的人利用，防范諸如“掉錢包”、“問路”等方式的欺詐；要注意犯罪分子利用短信來詐騙錢財；在ATM柜員機取款要環顧四周，確保沒有可疑人員時，快速操作，注意遮擋。等等等等。
 
我們老百姓何時變得如此專業和機敏，怪不得網上稱中國遍地都是專家和特工。我們在如此多的領域具有相當專業的水平，且冷靜沉著，判斷準確，意志堅定，身手敏捷。這簡直是一個擁有13億邦德的國度，還不讓美帝羨慕死。
 
其實我們寫代碼時，常常會面臨同樣的問題。我認為，如果一個設計依賴于其它設計的實現，那一定是有問題的。可是往往是這樣，我們需要了解太多的原理和實現，只有廣泛的學習，才能寫出一個能用的東西，即便是看起來不需要了解的部分，它一旦更改了實現（當然它不會通知你），你就方寸大亂，到處出錯。這時候你才知道，原來你是多么的脆弱，你多么需要它，需要學習。
 
假如我們在參數解包里存配置，而我不知道參數解包在高級中斷里，也不知道存配置里使用了信號量，更不知道在高級中斷里使用信號量會出錯。天哪，出了問題是誰之過。
 
就像我們不能責怪政府一樣，我們也不能責怪被調用函數的實現者，有時候我們確實想當然的做了一些事情，也怪我們知識水平不夠。但我們真的希望我們可以傻傻的活著，因為簡單就意味著少犯錯誤。
 
其實這一切歸根到底都是結構的問題，就像一個不好的體制會出現很多問題一樣，一個有問題的結構也會出現相應的問題。
 
但是好的體制在哪里，是美國式的民主嗎？
 
沒有好的體制，任何體制都有其問題。

 
相信各位牛人都寫過多線程的程序（暈死，我們現在恐怕很少項目是單線程的，就算有，還有幾個中斷例程搗蛋，相當于多線程），必定學過什么信號量呀、事件呀、同步呀、互斥呀、死鎖呀，研究過什么讀者寫者、生產者-消費者、哲學家就餐之類之類的。
 
好玩吧。
 
兩個不同優先級的線程搶占一個資源，高優先級搶低優先級的，喲，我鎖住。呵呵，把高的掛起，優先級反轉。低優先級剛拿到一個指針，高優先級的就把它釋放了（汗?。５蛢炏燃壍膭偱袛嗔艘粋€條件，高優先級的立馬把狀態改變，于是低優先級下面的動作全錯了。
 
資源爭奪，系統分析員不可回避的問題。但是我們往往都不夠重視這個問題，而今，高端參數部分的一個硬傷就是。多個線程公用變量和狀態，由此衍生了許多bug。那如何解決，終極之道不是如何協調各個線程，而是避免資源爭奪，減少資源公用。
 
一個男人一個女人，那是和諧社會；幾個男人一個女人，呃，那是光棍聚會？？?。‰y免你爭我奪呀。
 
記住這句話，這是我的，你要用，憑什么！
 
======
 
ps，突然想到關于領導的問題，假如有一個皇帝，見一民婦，貌甚美，預征用之，其夫忿，告之，乃我妻，望諒。帝曰，憲法云，普天之下，莫非王土，率土之濱，莫非王臣。刁民，還有什么是你的，都是我的，拿來吧你。
 
一個號稱管理者的類往往手伸得很長，聚合在它之下的類往往沒什么私人家當，跟奴隸沒什么區別，“管理類”才不屑去調什么接口函數，直接就拿了人家的內部變量（雖然有時候被迫聲明為public）來用，你不服，呀喝，我把你new出來的，你被我管著，還由了你了。這樣的代碼不少見呀，當然生活中更多。
 
再多說兩句：
1 私人財產神圣不可侵犯。
2 安得廣廈千萬間，大庇天下寒士俱歡顏，一人一套（唉，房子呀）。

仿函數可以代替函數指針，而且它可以保存狀態（類里面含有成員變量），相當于函數指針指向的函數有局部靜態變量，同時它可以同時存在多個實例。

      代碼審查除了顯而易見的對源碼本身正確性以及可維護性等方面的驗證，交流和學習也應該是其目的之一。和白盒測試相比，在很大程度上有共通之處，但側重點不同。代碼審查更偏重整體性，而白盒測試更偏重局部性。
      代碼審查一般基于3種目的，包括審查代碼風格，審查正確性以及是否與設計相符，還有特定目的的審查，比如效率、容錯性、安全性等等。對于我們來說，對于不同部分的代碼，可能有不同的目的，有時候甚至多種目的結合起來審查。但是不論如何，每次代碼審查都應該確定目的，有的放矢，否則可能很難控制時間和質量。
      形式上應該是多樣的，針對審查對象，應該有自查，互查，小組走讀等各種方式以區別對待，否則可能難以發現隱藏較深的問題，或者因大量的討論和會議喪失效率。但是如何區別就成了一個問題，對我們來說，什么樣的問題才需要小組走讀，由誰來判斷，如何判斷是需要明確的。
      代碼審查的資源消耗是非常大的，這取決于審查的形式，審查的目的（涉及深度和廣度），以及審查的頻率。要認識到成本收益比和邊際收益遞減的規律，當然我們目前審查不足，增加審查力度的邊際收益應該還是比較大的。還有一個問題就是過程成本，或者說管理成本，如何保證審查的有效性以及縮減組織審查造成的資源損耗，制度化、規范化應該是一個辦法。
      審查人員的素質也是關鍵的。不是說任何人都能成為審查人員，他必須在對象問題上具有一定的權威性，否則審查錯誤比不審查還要糟糕。而我們目前的情況是，所有具有一定資質的人員，都肩負著管理任務，大多數時間都消耗在公共、行政或者其它事務上，造成在審查力度上的不足，如何協調也是我們需要解決的一個問題。
      最后的一點是期望收益的問題。如果我們希望審查發現所有問題，或者實行對審查人員的問責制，可能會造成大家都不愿意去審查代碼。審查只是一個保證手段，就好像測試一樣。如果一旦發現問題，就責怪審查人員為什么沒有發現，那是不可取的。

1、

 
2、C++的異常處理是不可恢復的。
 
3、用懶漢式的單件如下，可能產生線程不安全。

首先，在判空時重入會被new兩次，其次，返回實例的指針，可能會被會被delete掉。

1、指向非靜態成員函數的指針不是普通的指針，要包含包括this指針等信息，具體取決于編譯器的實現。
2、指向虛的非靜態的成員函數形成虛調用，指向基類的成員函數的指針可以產生對派生類重載函數的調用，可以實現C＃中的委托。
3、委托？反射？托管？

1、研究了一下每日編譯的實現，主要是vss和vs.net的命令行方式工作，一個簡單的批處理如下：

究竟如何評估軟件成本（工作量）？COCOMOII太復雜，其它的計算方法并不適用我們，Deiphi？我們缺少真正的專家。僅僅從需求頁數、代碼行數、人月生產率、千行故障率、bug消除率、測試用例數、等等是否能夠估算出我們的工作量？我們的歷史數據是否足以代表我們的真實狀況？我們還要考慮到人員無法100％投入，在線問題的維護、部門或公司公共事務的處理，到底我們能投入百分之幾？太多的變數，讓這成為一個無法求解的方程式。
或許，只能慢慢地試，讓這個公式逐步求精，要接受失敗。

MOI——激勵、組織、創意
MOTIVATION(激勵)、ORGANIZATION(組織)、IDEAS/INNOVATION（想法/創意）
作為管理者，首先應該能激發下屬的工作激情，樹立他的自信心；然后能夠組織和協調整個團隊，在發生沖突，或者出現障礙時，能夠提出好的見解，雖然可能不是解決方案。

處理復雜問題的方法
鑒于人能處理復雜問題的規模，我們在解決一個復雜問題時，首要要想到的就是“分而治之”，而這一切的前提是，確定問題的范圍，沒有范圍的問題，是無法分割的，這就是規約的作用。

軟件風險管理
沒有任何一個軟件是沒有風險的，隱藏風險不如正視它，把風險列舉出來，在項目早期去規避它或者為它做準備，臨危不亂，可能更有效。但要注意的是，這一切的根本是如何識別風險，這需要領導者具有豐富的經驗和敏銳的觀察力。

調用堆棧的獲得：
     54：進入函數時，會調用 link a6 指令，將A6壓棧，再將棧頂指針存入A6，退出函數做相反操作。
     VC（debug）：進入函數時，會調用 push ebp ；mov ebp, esp，同54原理。退出函數做相反操作。
     以 VC 為例，說明調用堆棧的獲得。
     ebp-+     +--------------------+
         |     |    . . . . . .     |
         |     +--------------------+
         +---  |         sp1        |---+
               +--------------------+   |
               |         pc1        |   |
               +--------------------+   |
               |    . . . . . .     |   |
               +--------------------+   |
          +--- |         sp2        |---+
          |    +--------------------+
          |    |         pc2        |
          |    +--------------------+
          |    |    . . . . . .     |
 
        獲得 pc 指針的操作：

          若想得到函數名需要反查調試信息表。