2009年11月1日
在1998年的元旦，Bjarne Stroustrup（C++之父）接受了IEEE《計算機》雜志記者的專訪。編輯很自然的認為他會對于過去七年來使用他創建的語言進行面對對象設計做一個歷史性的回顧。而在這個專訪中，記者獲得了更有價值的新聞，但是最后編輯決定為了整個IT產業，這個稿子不能發表，但是就像其它被砍掉的新聞，往往還是弄得路人皆知的。
這一篇適當時專訪的完全拷貝，沒有被編輯、刪改或者做過什么潤色處理，也沒有發布過，可能看起來不像常見的雜志文章，但這是實情。
你會發現真正引人入勝的地方... ...
記者: 您在幾年前你改變了軟件設計世界的面貌，現在再回首往事您有什么感想？
Stroustrup: 事實上我在你到來之前的這些天里一直在考慮這件事，你還記得幾乎所有的人都在寫 C程序那會兒嗎？麻煩的是這些人寫得太好了，而且那些個大學也都在努力的傳授 C編程技術。的確他們是十分的成功——我要特別的指出"成功"這個詞——因為這種顯著的 C程序員的培養效率，這就是產生問題的原因。
記者: 這難道是個問題嗎？
Stroustrup: 當然，你記得大家都在用Cobol語言寫程序的時候嗎？
記者: 哦，當然，當時我也一樣。
Stroustrup: 在一開始的時候，這些人簡直象半個上帝似的拿著高工資，享受著貴族一樣的待遇。
記者: 唉，那些日子多么的讓人懷念，是吧？
Stroustrup: 當然了。但是接著發生了什么？IBM覺得這樣不舒服，就投資了數百萬來培養程序員，直到程序員多得一毛錢就可以雇一打。
記者: 這就是為什么當時我撤出來了，工資在一年里就降到人們在說做個記者都比程序員強的地步。
Stroustrup: 對啦！那時侯相同的事情發生在了C程序員身上了。
記者: 這個我明白了，可是您要說的是......
Stroustrup: 有一天，我坐在辦公室里就在想如何能把這件事挽回一些。我想知道如果有一種特別復雜而且難以學會的語言，是否就沒有人可以又把程序員們搞到市場的泥潭里去呢？我用了從X10里了解到的東西，，噢，就是X-Windows，真是一個該死的圖形系統，只能運行在那些個SUN 3/60的機器里，哈！它具有所有我想要的特征：可笑而復雜的語法，含混的功能描述，還有偽裝的OO結構，就算是在現在，還是沒有人愿意用那些東西，如果你不想發瘋的話，Motif才是唯一解決方案。
記者: 你是在開玩笑嗎?
Stroustrup: 沒有，事實上還有另外的一個問題，UNIX是用C寫的，就是說任何一個C程序員都可以很容易的成為系統程序的開發者。還記得一個大型的主機系統應用的開發者通常能掙多少錢嗎？
記者: 你肯定是知道我當時就是干這個的。
Stroustrup: 好吧，因此這個新的語言一定要通過隱藏所有的系統調用來和UNIX分離開來，這樣可以使那些個就只是知道DOS的人也可以活得很體面。
記者: 我不大相信您說的這個......
Stroustrup: 而且到現在時間也夠長的了，我相信有很多的人已經指出了C++是對時間的浪費，我要說的是，這個過程比我想象的要長的多了。
記者: 那么您又是如何做到的呢？
Stroustrup: 那只是一個玩笑，我真的沒有想到人們會對那本書那么認真。任何人只要長了半個大腦也應該明白面對對象編程是荒謬而不合邏輯的，而且效率低下。
記者: 什么？
Stroustrup: 再說代碼重用，你什么時候聽說過有公司重用他的代碼？
記者: 事實上從來沒有，但是......
Stroustrup: 那么我提醒你一下，在早期有很多的例子。哦，有一家叫Menter Graphics的俄勒岡州公司，我認為他們應該是感冒了，竟然在90年或者是91年把所有的代碼用C++重寫了一遍，對不起，我實在是想不起確切的時間了，我看大家應該從這個事件中吸取教訓。
記者: 沒有人真正的吸取了教訓嗎？
Stroustrup:
沒有，而且還有很多公司犯同樣的錯誤，還向他們的股東解釋說那3億美圓的損失是正常的，他們就是做了這樣的事情。
記者: 真的？可是這也只能證明OO方法是能夠工作的，不是嗎？
Stroustrup: 也許吧，執行文件是那么大，在一臺有128M內存的HP工作站上只是裝載到內存中就要用5分鐘時間，然后將象毛毛蟲爬樹一樣的運行。事實上我在第一個禮拜就發現了這個缺點，奇怪的是好象沒人在乎這個，Sun和HP好象只在乎買出那些功能強大的各種玩意兒，而不在乎在上面跑什么程序。在AT&.T的時候我編了一個"Hello World"程序，簡直是難以置信，執行文件有2.1M。
記者: 那么大？是啊，就是從那時候開始的編譯程序產生大個的文件的。
Stroustrup: 就是這個樣子，如果你不信的話，可以用最新版的g++試一下，你得到的東西不會小于0.5M，而且就在最近也有一些在各個國家的例子，比如在British Telecom公司發生的災難，但是幸運的是他們把原來的計劃廢棄了，又重新開始，他們就比Australian Telecom公司幸運，現在我又聽說Siemens公司又在造"恐龍"了，他們目前是越來越擔心要用來加速執行軟件所要使用的昂貴的高速硬件，難道你真的認為那些個多態繼承是一種樂趣嗎？
記者: 噢，但是C++的確是一種可靠的語言啊！
Stroustrup: 你是真的相信的，對吧？你有沒有真的坐下來用C++開發過項目？我來告訴你會發生什么：首先，我會加入足夠的缺陷來讓那些微不足道的模塊先執行，讓工作超載，在工程掃尾的階段，你回發現幾乎所有的模塊都會有這種缺陷，這是因為人們以為就是應該這樣做，因為在C++的教程中就是這樣寫的。在相同的模塊中執行不同對象的相似操作意味著：有一些東西在各個模塊中是完全不相同的。當你有了互不相同的上百個這樣的模塊，就可以把他們集成在一起了。其次，我再說說所謂的數據隱藏，上帝啊，當我聽說了有的小組實現了什么對象協同通信，我真的是憋不住想笑！我看，OO方法中的"協同"這個詞可以把項目經理的肋條累斷。
記者: 我不得不說著太可怕了！你還說這是用來提高程序員的工資，這太齷齪了！
Stroustrup: 齷齪？不是這樣的，任何人都有選擇的權利。我是并不想讓事情發展成這個樣兒的。不管怎么說，我基本上還是成功的。C++現在已經不行了不是？而且程序員現在還是能掙到高工資的——特別是那些還要維護這些該死的"++"東西的那些程序員。你應該明白如果你去維護一個不是由你開發的C++模塊是不可能的。
記者: 怎么會這樣的？
Stroustrup: 你糊涂了？還記得typedef嗎？
記者: 噢，當然。
Stroustrup: 知道要在頭文件里發現象'RoofRaised'這樣的變量是一個雙精度數要用多長的時間嗎？想象一下要在一個工程里所有的類定義里尋找那些typedefs
... ...
... ...
記者: 那么你為什么認定你已經成功了呢？
Stroustrup: 還記得一般一個C程序項目要多長時間嗎？一般是6個月。這對于一個要養活妻子孩子的程序員是不夠的。如果是一樣的項目，但是用C++來開發，會怎么樣呢？我告訴你：要一兩年才能做完！這不好嗎？就是一個小小的編程語言選擇的決定，語言程序員就不會輕易的下崗了不是？而且那些個大學已經很久沒有傳授C了，現在是對C程序員的短缺。特別是對UNIX編程熟悉的程序員。在使用了這么多年的"new"以后，而且一直以來一直都不用擔心返回值的問題。還有多少程序員知道使用"malloc"？事實上，大多數的C++程序員舍棄了返回值，無論什么樣的結果，甚至于返回了"-1"，其實用不著什么'throw'、'catch'、'try'之類的東西，至少你應該知道產生了錯誤。
記者: 但是繼承的確不是可以節省很多時間的嗎？
Stroustrup: 是嗎？你注意過C項目計劃和C++的項目計劃之間的不同嗎？在進行了三次系統功能分解后，要確定所有的東西都可被繼承到，如果沒有那么說明還是有錯，但是有誰在C編程里聽說過存儲滲漏這個說法？現在你可以在業界的大廠商的產品中發現了！有很多的公司不得不放棄了，并且把工程轉包出去，他們知道最后可能象篩沙子似的把內存站用完，他們才不想遭那份罪呢！
記者: 也有一些工具來......
Stroustrup: 大多數的防滲漏的工具不還是用C++寫的。
記者: 果把這些東西發表了，我們可能在這個行業里無法立足了，你知道嗎？
Stroustrup: 我不相信，就象我所說的，現在C++已經是在垂死掙扎了。任何公司只要清醒，就會認識到用C++來做項目簡直是一場災難。如果還沒認識到這些，那就是活該！有一段時間我使勁的勸Dennis Ritchie用C++重寫UNIX。
記者: 啊？天哪！他是怎么說的？
Stroustrup: 我不得不承認他的洞察力，我想他和Brian在很早的時候就清楚的明白了我的意圖，但是從來沒有說出來，他說如果我愿意的話，他可以幫我用C++寫
個DOS。
記者: 那么你寫了嗎？
Stroustrup: 事實上，我寫了，我完成后可以給你一個DEMO，我在機房里的一臺4個CPU的Sparc 20上做的，運行得特別的快，而且只占了70M的硬盤空間。
記者: 有For PC的版本嗎？
Stroustrup: 現在你在開玩笑了，難道你沒見過Windows 95嗎？我認為它是我成功標志之一，
記者: 我也總是在想關于Unix++，還是有人在試著搞這么個東西的。
Stroustrup: 那是因為他們還沒有看到這個采訪手跡。
記者: 對不起，不過依我看，我們恐怕不會刊發這些東西的。
Stroustrup: 但是這是個世紀故事，我只是想讓我的程序員伙伴們記住我為他們做了什么，你知道這些個日子里C++程序員可以掙多少錢嗎？
記者: 我所聽說的是一個頂尖的C++程序員一小時可以掙到70～80美圓。
Stroustrup: 知道了吧！而且我打賭他肯定可以掙那么多！！單步跟蹤我放在C++里面的那些gotcha，并不是容易的事了。在在項目中使用C++的所有特性即使是有經驗的程序員也會感到困惑. 事實上有時侯我也是覺得挺難受的，雖然這個特性是為我的初衷而做的，我幾乎喜歡上了這個語言。
記者: 你的意思是說你以前是不喜歡的？
Stroustrup: 我是狠它的！難道你不同意它是挺笨重的嗎？但是當那本書的版稅源源不斷的...... 我想你能夠明白這些。
記者: 等一下，關于參數的定義，請您一定要回答，您是否真的改良了C的指針。
Stroustrup: 呵，我也是總是想知道這個。一開始我認為我做了，但是有一天我和一個剛開始學習 C++的程序員討論了這個問題。他說："他從來就不知道他的變量是否被引用了，所以我還是在使用指針，那個星號總是在提醒我。"
記者: OK，一般在這個時候我一般是說："Thank you very much."，但是現在用在這里好象還是不夠。
Stroustrup: 答應我一定要發表。
記者: 好的，我會通知您的，但是我已經知道了我的編輯會說什么了。
Stroustrup: 誰會相信呢？你能把這盤錄音帶給我拷一個嗎？
記者: 可以。
正文完
2009年6月2日
摘要: Google Test是Google C++ Testing Framework的一種非正式的稱謂，是google最近發布的一個開源C++測試框架。
Google測試框架是在不同平臺上（Linux，Mac OS X，Windows，Cygwin，Windows CE和Symbian）為編寫C++測試而生成的。它是基于xUnit架構的測試框架，支持自動發現測試，豐富的斷言集，用戶定義的斷言，dea...
閱讀全文
2009年5月18日
C++界面庫 - Xtreme Toolkit Pro[轉載]
原文轉自：http://blog.csdn.net/vbvan/archive/2007/11/23/1899282.aspx
一套擴展MFC的界面庫，可以很方便的實現各種界面風格。不過話說VC2008的MFC即將集成它競爭對手的產品BCGControl，呵呵
官方網站：http://www.codejock.com/products/toolkitpro
最新的11.20版本已經支持VC2008了，所以編譯沒有太大的問題。要注意的一點是，源文件的注釋有一些非GBK字符，編譯的時候命令行里最好加上/wd4819
使用的時候，只需要在StdAfx.h中加入下面的語句即可
#include <XTToolkitPro.h>
如果你選擇static link，那么可以使用宏把不需要的部分排除掉，這樣能減少最終生成的EXE的大小
//#define _XTP_EXCLUDE_COMMON
#define _XTP_EXCLUDE_TABMANAGER
#define _XTP_EXCLUDE_GRAPHICLIBRARY
//#define _XTP_EXCLUDE_CONTROLS
//#define _XTP_EXCLUDE_COMMANDBARS
//#define _XTP_EXCLUDE_DOCKINGPANE
//#define _XTP_EXCLUDE_PROPERTYGRID
#define _XTP_EXCLUDE_REPORTCONTROL
#define _XTP_EXCLUDE_CALENDAR
#define _XTP_EXCLUDE_TASKPANEL
#define _XTP_EXCLUDE_SHORTCUTBAR
#define _XTP_EXCLUDE_SKINFRAMEWORK
#define _XTP_EXCLUDE_RIBBON
#define _XTP_EXCLUDE_SYNTAXEDIT
另外值得注意的一點是，如果你選擇static link，那么需要將XTP的資源導入你的工程之中。比如要使用中文資源，那么把下面的代碼加入工程的rc2文件的最后
#define _XTP_RESOURCE_LANGUAGE zh_CN
#include <XTToolkitPro.rc>
同時，你還需要修改一下XTP附帶的XTToolkitPro.rc中的內容
將最后的LANGUAGE_DEFAULT(TaskPanel)改成LANGUAGE_LOCALIZED(TaskPanel)
然后在TaskPanel\res目錄下將Resource.rc復制成Resource_zh_CN.rc，并將其中的編碼改成中文
#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_CHS)
#ifdef _WIN32
LANGUAGE LANG_CHINESE, SUBLANG_CHINESE_SIMPLIFIED
#pragma code_page(936)
#endif //_WIN32
#endif
否則你之后include的資源會變成默認的英文
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
產品介紹：http://blog.csdn.net/componentcn/archive/2007/04/19/1570086.aspx
2009年5月4日
關于設計
設計是一項把需求轉換為編碼方案的活動。設計在軟件開發中是必定存在的，無論何種情況下，我們都需要把需求轉化為編碼方案。
設計是一個不斷完善的過程，設計的缺陷可能在設計之初無法被發現，直到設計完成時才被察覺到，這導致了再次設計的需要。注意，我們在首次設計時應該盡可能的避免缺陷的出現，而不是視而不見以求下次解決。
設計上的付出是必要的，在設計階段發現錯誤并改正比編碼后發現相同錯誤并改正的代價低的多，如果設計的錯誤拖延到維護階段，那就更加不堪設想。
設計存在優劣，必須明確這一點。敷衍的進行設計后果是很嚴重的（雖然偶爾也能更加快速的產生產品），糟糕設計的最大特點是無法響應需求變更。但也應該注意，優秀的設計有多種，糟糕的設計也有多種。
事物的本質屬性是一件事物必須具有的，如果不具有則就不在是該事物。事物的偶然屬性是不起解決性作用的屬性。例如，車總有輪子，沒有了輪子就不在是車，那么輪子就是本質屬性，但是輪子可能有 4 個，也可能有 3 個，無論多少個輪子依然是車，那輪子的數目就是偶然屬性。
本質復雜度源于需求，無論采取何種手段，何種技術都不會對本質復雜度造成任何影響，所以有人才會說，軟件開發本身就很復雜（無論使用何種技術開發都是復雜的）。我們需要管理好偶然復雜度（偶然性的復雜度），例如，需求是開發一個可用的計算器程序（圖形界面可有可無），這時，開發命令行的計算器就比開發 GUI 的計算器的偶然復雜度小，用 C++ 進行開發其偶然復雜度就比用 Dephi 高。敏捷開發和 Unix 中都強調 KISS，而敏捷開發更加強調應該使用簡單的技術和工具，這都是為了避免偶然復雜度過高帶來額外的成本開銷。
設計者應該真正理解偶然復雜度，如果設計出來的框架，在進行開發時需要開發人員關注于系統的每個細節，那么對于程序員來說偶然復雜度是高的，相比下，對于每個功能的開發，程序員只需要關心當前編寫的任務，那么偶然復雜度是低的（COM 的設計非常強調的一點是封裝，而不是復用）。
設計的基本的原則：
1）盡量降低偶然復雜度。如果可以簡單的解決問題，那為什么不這么做了？另外某些角度來說：
模塊化的系統（系統對“模塊”一詞有確切的定義），在一定程度上偶然復雜度較低，模塊化的系統讓程序員只需要關心當前開發的部分。
2）盡量保持高內聚，低耦合。高耦合的系統懼怕變動（動一處而牽動全身），變動帶來的問題通過關聯進行傳遞。高耦合的系統的關鍵點在于：系統組成部分的關聯過多，導致過多的相互影響，當關聯數量到一定程度，整個系統就會很不穩定。
具體來說：
<1> 集成的困難：高耦合的各個程序組成部分需要花費較多時間進行集成。
<2> 測試的困難：一個部分的問題通過與其他部分關聯傳遞到其他部分，那么意味著一個部分的變動可能導致整個系統的重新測試。
低耦合：在類這個層次上來說，除了底層的工具類（例如 STL）之外（工具類允許和系統中的大部分類發生關聯），應該盡可能的減少類之間的關聯。
3）可擴展。可擴展的一個標志是，無需改變系統底層，即可增加新的功能。
4）可移植性。可移植性非常特別（似乎違背低偶然復雜度原則），它不同于軟件的其他的特性，除非你保證你的項目永遠無需移植到其他的環境中去，否則，你應該注意這點，因為通常來說，時間越長，越難移植，甚至最后只能重寫，代價非常之高。
5）分層。分層的系統相對來說偶然復雜度較低，關聯較少。每層都有每層的工作，相互影響較小。
另外，類的粒度也比較重要，大粒度的類間關聯少，但是不可避免的就是類自身過于復雜。小粒度的類自身很簡單，易于開發和維護，但是類間關聯變多，通訊太頻繁。粒度過大和過小都會帶來較多的問題，應該根據經驗作合理設計。
在 C++ 中使用巨大的類無異于使用 C 語言進行編程，這意味著你拋棄了 C++ 強大的抽象能力。含有巨類的系統中的一個顯著的標志是：含有大量重復代碼或者相似代碼（這歸結于 C 語言不夠強大的抽象能力和項目在時間上的壓力）
最后要說的一句是：KISS 和敏捷給太多人以誤解，請仔細斟酌它們的含義（有幾個人懂得 KISS 的真正含義）。設計是不可避免的，好的設計是至關重要的。好的設計在一定程度上控制了軟件的成本，即使你的老板并不明白，但是你應該這么做。
author: killercat
2009年5月3日
01領先定律
成為第一勝過做得更好
在中國市場上，茅臺是第一種高檔白酒；中華是第一種高檔香煙；健力寶是第一種運動飲料；三槍是第一個內衣品牌；脈動是第一種維生素水；康師傅是第一種高檔方便面和瓶裝綠茶；金龍魚是第一個調和油品牌；東方紅是第一個拖拉機品牌。今天，除健力寶因企業內部原因導致品牌衰落外，極大多數品牌都仍然占據各自領域的第一位置。
02品類定律
如果你無法在現有品類中成為第一，那么就創造一個新的品類使自己成為第一。
中國橙汁飲料市場的例子很好的說明了這一定律；匯源成為高濃度果汁的第一品牌之后，鮮橙多開創了低濃度果汁品類，并成為該品類第一；酷兒開創了兒童低濃度果汁品類；美汁源則開創了果肉果汁（果粒橙）品類，成為該品類第一。這些品牌都因開創了一個新品類而獲得成功。
03心智定律
在心智中成為第一勝過在市場中成為第一。
喜之郎并非國內第一個果凍品牌。在喜之郎之前，金娃等品牌已經率先進入市場，但從全國來看，顧客心智中并沒有一個公認的果凍品牌，也就是說，首先進入市場的果凍品牌并未進入顧客心智。于是喜之郎依靠突出的形象，并率先在CCTV等大眾媒體上進行廣告宣傳，成功搶先占據心智，從而收獲了果凍市場50%以上的份額。
后來，喜之郎公司又故伎重演，推出了美好時光海苔，試圖通過大眾媒體搶占方便海苔品類，不同的是，方便海苔品類中已經有波力等品牌先入為主，因此美好時光投放了大量廣告也沒有取得預期效果。
2003年年初，長富出現在央視黃金時段，正式吹響了進軍全國的號角。
長富宣稱其牛奶“綠色天然”，是“真正順滑香濃的好奶”。為了證明其“高品質奶源”，長富召開新聞發布會，展示其地處福建武夷山區據稱是中國最大最好的奶源基地。后來，長富更是不惜血本，在廣東展開“買24送15”的促銷活動，盡管長富投入了9200萬元的廣告費，但市場并不為其所動，全國乳業市場的格局并沒有因為長富的加入而被打破，甚至連長富最為看重、投入最多的廣東市場，也沒有實現其市場占有率10%的目標。
擁有一流產品以及廣告投入巨大的長富為什么會折戟沉沙呢？
原來，在消費者的心智中，“最好的奶源來自內蒙古大草原而不是武夷山”。之一觀念早就隨著“天蒼蒼，野茫茫，風吹草低見牛羊”的詩句深入人心。加之蒙牛、伊利此前早就在合力宣揚“內蒙古牛奶好”。所以，盡管長富說“如今的內蒙古大草原水土流失嚴重，日益風蝕沙化，而武夷山處于北緯27度，有中國‘澳洲’之稱”，但畢竟勢單力薄，無法改變消費者心目中“最好的奶源來自內蒙古”這一認知。
統一與康師傅在中國大陸市場競爭的實質就是一場先入為主的戰爭，康師傅進入大陸市場之前在臺灣默默無聞，統一則是臺灣食品飲料領域的領導者，康師傅率先進入大陸市場推出了中高檔方便面，統一隨后進入，但康師傅已經先入為主，因此在大陸市場上，實力更強大的統一在方便面領域一直落后于康師傅。之后，康師傅又搶先推出瓶裝綠茶、冰紅茶等產品，這些產品的市場份額都無一例外的領先于統一。統一唯一的翻身機會在于率先推出了低濃度果汁“鮮橙多”，后來，康師傅跟進推出低濃度果汁品牌“鮮的每日C”，其銷量當然是遠遠落后于“鮮橙多”。
04認知定律
市場營銷不是一場產品之戰，而是一場認知之戰。
歷史總在不斷的重演，可口可樂和百事可樂所做的實驗，中國的非常可樂也做過，非常可樂也曾經宣稱：經過上千次配方改進，測試證明非常可樂更適合中國人的口味。遺憾的是，非常可樂更好的口味無法阻擋可口可樂和百事可樂在中國市場取得成功。
張裕干紅葡萄酒在國內大部分地區以“百年張裕”的歷史資源來向人們推廣“國產高檔葡萄酒”的認知，但在廣東地區，張裕品牌卻更多地代表低端白蘭地。原因在于，張裕低端白蘭地在該地區有較長的銷售歷史、極高的知名度和占有率。這種強烈的認知也影響到張裕的高端干紅在該區域難以打開局面。
05聚焦定律
市場營銷最重要的是在潛在顧客心智中占據一個字眼。
在美國市場，佳潔士以聚焦“防蛀”概念而成為第一，但在進入中國市場之初，佳潔士因擔心“防蛀”市場有限，轉而宣傳口氣清新、美白等概念，被一直處于第二的老對手高露潔抓住機會，搶先聚焦于“防蛀”概念。等佳潔士重新聚焦于“防蛀”之時，高露潔已經先入為主，成為“防蛀”牙膏的代名詞，并一直領先于對手。
在中國市場的研究表明，大部分購買高露潔的顧客，真正的目的并非為了“防止蛀牙”，而是高露潔專注于“防止蛀牙”而建立起的專家形象，讓顧客認為這個品牌的牙膏更先進、更科學、更能保護牙齒。這就是“光環效應”的體現。
曾經被譽為“中國魔水”的健力寶，錯過了“聚焦定律”的機會，它當時有條件聚焦于“運動飲料”的概念，舍棄各種汽水、果汁、水、茶等產品，通過極力推廣運動飲料而使品類做大做強。隨著人們生活水平的提高，對運動的投入程度也越高，運動飲料的前景本來一片光明，可惜健力寶企業卻推出了定位不明的新品牌“第五季”，還分兵進入酒業，離正道越來越遠。
06專有定律
兩個公司不可能在潛在顧客心智中擁有同一個字眼。
金龍魚因開創了調和油品類而成為國內食用油的領導品牌，因此金龍魚成了“調和油”的代名詞。但隨著市場的發展，新的單一油種不斷興起，金龍魚品牌開始推出花生油、葵花籽油、菜籽油、玉米油等多個品類。但在這些品類中，魯花已經代表花生油、多力已經代表葵花籽油，金龍魚無法將已經被這些品牌在顧客心智中注冊的字眼和概念占為己有，還面臨“調和油”的認知被稀釋，最后淪為混沌品牌的危險。
07階梯定律
市場營銷戰略取決于你在潛在顧客心智階梯中的層級。
階梯定律背后蘊涵的營銷真諦是：在營銷中，心智決定市場；品牌的心智地位決定市場地位；心智份額決定市場份額；蒙牛品牌創立之初，面對強大的伊利，并未采用正面進攻的方式與之競爭，而是打出“創內蒙乳業第二品牌”的口號，在顧客心智中與內蒙古第一品牌伊利直接產生關聯，達到了迅速有力地提升了蒙牛品牌的心智地位的功效。同時蒙牛很默契地與伊利共同推廣“草原奶”的概念，推動了自身品牌的高速增長。
08二元定律
長遠來看，任何一個市場都會演化成“兩匹馬賽跑”的局面。
行業巨頭的二元化局面在中國企業中已經初步顯現：茶飲料領域是康師傅和統一；高檔白酒領域是茅臺和五糧液；乳業市場是伊利和蒙牛；內衣市場是三槍和宜而爽，……可以預見，隨著競爭的加劇，尤其是中國加入WTO以后，競爭壁壘逐漸打破，二元定律在各個領域開始顯現出威力，“兩匹馬競爭”的局面將廣泛存在于各個行業中。
09對立定律
若想成為市場第二，那么你的戰略應由第一決定。
“鮮橙多”在低濃度果汁市場上取得成功之后，匯源、哇哈哈、康師傅紛紛跪進退出相應的模仿產品，但真正成為低濃度果汁領域中第二的品牌并非以上跟進者，而是遵循了對立定律的“酷兒”。與“鮮橙多”面向大眾不同，“酷兒”將顧客群定義為“兒童”，并在配方中加入“鈣”，從而成為兒童首選的低濃度果汁。
廣州報業市場上，《廣州日報》依靠開國內市民報之先河獲得迅速發展，成為國內廣告收入第一的報紙。面對強大的《廣州日報》和老牌的《羊城晚報》，《南方都市報》在面市之初采取了對立面戰略，針《廣州日報》的大版面、權威、穩重的特點，《南方都市報》采用小版面突出新銳、時尚、從而獲得了年輕白領的青睞，一舉成為廣州第二大報。
最近三年里，QQ成為奇瑞汽車最為暢銷的車型，并一舉超越奧托成為小型經濟型轎車的代表。QQ用時尚、活力、現代的品牌概念一舉將奧托定義成老舊、過時、缺乏活力。QQ成功的關鍵在于成為原先領導者奧托的對立面。
10分化定律
長期來看，每個品類都將分化成兩個或更多品類。
微軟在3C計劃上浪費了數十億美金，沒有任何結果。在中國，3C融合一直被家電企業當做必然的趨勢，TCL就是一個典型。從20世紀90年代中期開始，TCL為3C計劃投入了巨資，并為此挖來了有“打工皇帝”之稱的微軟前中國區總裁吳士宏，最終卻以信息家電失敗、吳黯然辭職而收場。
分化在各個品類中時有發生，以啤酒行業為例，最初是普通啤酒，后來分化出淡啤、清啤、純生、無醇、黑啤等很多個品類；再如瓶裝茶飲料，最初是綠茶，后來分化出冰紅茶、冰綠茶、紅茶、烏龍茶、茉莉花茶；電視機分化為：CTR、液晶、等離子等品類，甚至空調也分化為中央空調和家用空調，家用空調則進一步分化為臥室空調和客廳空調等種類。
11長效定律
市場營銷的改革需要從長期來看。
詮釋長效定律最好的反面例子莫過于春蘭空調。1994年春蘭空調銷售額達53億，居國內第一，1995年春蘭確定了2000年銷售額達到180億的目標，為了達到該目標，春蘭進入了彩電、冰箱、洗衣機、摩托車、卡車等領域，銷售額實現快速增長。到了2000年，春蘭空調銷售額達到185億，但利潤開始下滑。到了2005年，春蘭多元化的惡果開始顯現，持續出現虧損，最終被迫退出股市。
在中國白酒行業里，大量的投入和促銷并沒有建立起新的強勢品牌，而高額的促銷、返利、終端費用拖垮了越來越多的企業，行業的領先品牌依舊是幾乎從不做促銷的茅臺、五糧液、劍南春。
12延伸定律
產品越多，市場越大，陣線越長，賺的錢反而越少。
娃哈哈品牌從AD鈣奶延伸到瓶裝水、果汁、綠茶、方便面、牛奶、童裝等領域，并在短期內實現了銷量的增長。哇哈哈的品牌延伸一度被國內部分營銷人士稱為品牌延伸的的典范，并以此為據反駁定位理論。但實際上，娃哈哈的品牌延伸稀釋了人們對該品牌的認知，娃哈哈在延伸領域幾乎沒有一個處于“數一數二”的位置，利潤也大幅下滑，這也成為其被迫與達能合資的主要原因。
國內許多企業均成長于需求高漲的特殊時期，憑借制造能力和渠道能力，很容易涉足多產品領域，現在比較成功的企業幾乎都是一個品牌橫跨多個行業，造成了品牌延伸容易做大做好的錯覺。隨著各行業競爭增強，企業要普遍承受“延伸定律”帶來的壓力。看看中國最優秀的一些企業，像海爾、康佳、娃哈哈、春蘭，都在進行品牌延伸，這種情形著實堪憂。雖然它們目前仍然“成功”，但就像一架不符合力學原理的飛機一樣，飛得越高越讓人擔心。
在汽車領域，東風也建造了一頂巨大的帳篷，東風曾經代表卡車，如今東風品牌不僅代表重卡、中卡、輕卡、小卡、面包車、客車，還代表法國轎車（東風標志）、日本轎車（東風日產）、韓國轎車（東風悅達·起亞）、國產MPV（東風風行），這就是東風品牌最致命的營銷問題。重卡和輕卡分別被專家品牌占據了兩個品類的主導位置，東風處境尷尬。
13犧牲定律
你如果想取得成功，就必須犧牲一些東西。
中國傳統的老八大名酒中，茅臺、五糧液、劍南春三個品牌發展成了全國性的領導品牌，并占據了行業的前三名，其余汾酒、古井貢等五個品牌則發展成了區域性品牌，在同一起跑線上的品牌為何有不同的結果呢？進一步對比就可以發現，三個全國性品牌共同的特征是聚焦于一個檔次——很短的產品線；五個區域性品牌的共同特點則恰恰相反，全都有多如牛毛的產品，產品覆蓋高中低檔。以汾酒為例，汾酒的產品多達800多個，其營銷負責人還聲稱“還遠不夠，還無法滿足需求”。
紅河卷煙廠依靠聚焦于一個品牌——紅河，同時紅河品牌聚焦于3-10元之間的中低檔香煙市場，從而獲得了巨大的成功，紅河品牌很快成為國內香煙銷量最大的三大品牌之一。其后，紅河不再滿足于低端市場，他先后推出了價格超過70元的紅河V8、并在10元以上市場先后推出了紅河88、紅河V6等產品，這些產品無一例外地以失敗而告終，同時也使紅河喪失了成為“中國萬寶路”的絕好機會。
14特性定律
想要成功，就必須有自己獨特的認知或特性，并以此為中心展開營銷。
王老吉涼茶以“預防上火”的特性獲得成功之后，國內飲料企業紛紛推出各種涼茶品牌。雖然表面看來這些品牌都有“賣點”，如：“老翁”宣傳的“臺灣涼茶”概念；“鄧老”則先后宣傳“中國涼茶道”和“時尚涼茶”；“何其正”宣傳“清火氣、養元氣”等，實際上這些品牌都未能聚焦有效特性，更未能從王老吉的對立面發掘出針對性這一特征，從而也未能成為涼茶領域的“百事可樂”。
15坦誠定律
使自己產品深入人心的最有效方法是，首先承認自己的不足，之后再將其轉變為優勢。
在營銷中使用“坦誠”定律需要極大的勇氣，中國企業在此方面的實踐案例較少。當企業面臨危機的時候，坦誠往往是必須的。三聚氰胺的危機使三鹿這個國內奶粉領域的領導品牌在一夜之間化為烏有，甚至影響到了整個乳品行業，如果在危機到來的第一時間三鹿想到了坦誠定律并付諸行動，及時向大眾承認問題，并召回產品，承擔責任的話，三鹿本可以避免這場滅頂之災。
16唯一定律
大多數情況下，你的競爭對手只有一個容易攻破的薄弱環節，正是這個環節，應該成為你全力攻擊的焦點。
可口可樂在中國瓶裝茶市場上進行過六次嘗試，先后推出過“天與地”茶飲料、藍楓日式蜂蜜綠茶、陽光冰爽果茶、雀巢“西式冰爽茶”、茶研工坊“草本茶飲料”，都以失敗而告終，最近推出的“原葉”系列雖耗資巨大，但也前景黯淡。可口可樂要在茶飲料上有所作為，就必須找到競爭對手最易攻破的薄弱環節，否則一切都將徒勞無功。
17莫測定律
除非是你為競爭對手制定計劃，否則你無法預測未來
在競爭最為激烈的家電行業，對未來的預測和判斷直接影響到中國品牌的整體表現。90年代，中國企業逐步掌握CRT彩電的核心技術，在中國CRT電視機市場中，中國彩電企業更曾占據98%以上的份額，索尼、東芝等品牌的CRT產品一度撤出中國。但中國彩電企業都未能預料到CRT將迅速衰退，液晶顯示很快成為市場主流。2005年開始，索尼、夏普、LG\三星等日韓彩電企業憑借液晶平板產品卷土重來，迅速占領了中國內地一二線城市市場，中國家電品牌鮮有液晶面板生產能力，被迫集體退守三四級市場。
即使在新技術的發展方向，彩電企業一度普遍認為等離子大屏幕彩電將成為市場主流，于是松下、富士通、NEC以及中國的長虹等大批企業則押寶等離子技術，夏普、三星等企業則大力投入研發液晶平板計數。如今，市場證明最初不被看好的液晶顯示屏成為了主流。
18成功定律
成功經常導致自大，而自大導致失敗。
企業因專注、聚焦而成功，一旦成功就感覺無所不能，擯棄最初的成功經驗。從某種程度上講，大部分國內知名企業都經歷了盲目擴張、多元發展然后陷入困境這一幾乎必然的過程。從聯想、海爾、TCL、長虹、奇瑞等各個企業身上都可以看到“成功定律”的影子。打破“成功定律”的宿命或許是中國企業面臨的最大挑戰。
19失敗定律
面對失敗，更佳的戰略是盡早發現錯誤并及時采取措施以停止損失。
如果失敗無可避免，那么及時撤退可以起到亡羊補牢的效果。聯想出售手機業務、創維以2元的低價出售手機業務都屬于此類舉措。所以，無論是聯想還是創維，消息宣布之后，股市都以大幅反彈作為回應，證明及時放棄屬于重大利好已是共識。
20炒作定律
實際情況往往與媒體宣傳的相反
CCTV黃金時間廣告招標的首屆標王秦池可謂闡釋“炒作定律”的最佳案例，借助大規模的廣告投放以及“標王”效應帶來的大量媒體報道，在較短時間內，秦池的知名度和關注度空前提升，這同時也為后來負面新聞的產生及迅速擴散累積了巨大的勢能，最終導致了無可挽回的結果。
21趨勢定律
通過淡化時尚，就能使產品流行的時間延長，從而使它更像是一種趨勢。
與趨勢定律相悖，很多企業追逐的恰恰是成為時尚與潮流。健力寶推出的“第五季”飲料正是希望通過時尚和潮流來推動品牌的成長，該品牌涵蓋了可樂、茶飲料、純凈水、果汁等品類，口號為“現在流行第五季”。在一陣風潮之后，第五季幾乎一無所剩。
22資源定律
就算是世界上最好的想法，如果沒有啟動資金，它也不會成為現實。
如何使市場第一成為心智第一，充分的資源是必須的，國內企業界流傳的“萬燕悖論”：先驅者往往成為先烈；從某種意義上正是說明了資源的重要性。萬燕發明了VCD，但是愛多和步步高卻通過大規模的廣告傳播率先搶先占據了顧客心智，最終，萬燕只能以失敗收場。因此，對于創業家而言，找到好的戰略與找到足夠的錢同樣重要。
營銷領域的黃埔軍校，國內洗化領域的領導者寶潔公司深諳資源法則的重要性，保潔一直是國內最大的廣告主，每年有多達16個億以上的廣告預算，每一個新產品的推出都有龐大的預算提供有力的支持。
2009年3月23日
至從C語言開始enum類型就被作為用戶自定義分類有限集合常量的方法被引入到了語言當中，而且一度成為C++中定義編譯期常量的唯一方法（后來在類中引入了靜態整型常量）。
根據上面對enum類型的描述，有以下幾個問題：
1.到底enum所定義出來的類型是一個什么樣的類型呢？
2.作為一個用戶自定義的類型其所占用的內存空間是多少呢？
3.使用enum類型是否真的能夠起到有限集合常量的邊界約束呢？
4.大家可能都知道enum類型和int類型具有隱示（自動）轉換的規則，那么是否真的在任何地方都可以使用enum類型的變量來代替int類型的變量呢？
1. 到底enum所定義出來的類型是一個什么樣的類型呢？
在C++中大家都知道僅僅有兩種大的類型分類：POD類型（注（1））和類類型。
enum所定義的類型其實屬于POD類型，也就是說它會參與到POD類型的隱示轉換規則當中去，所以才會出現enum類型與int類型之間的隱示轉換現象。
那么也就是說enum所定義的類型不具備名字空間限定能力（因為不屬于類類型），其所定義的常量子具備和enum類型所在名字空間相同的可見性，由于自身沒有名字限定能力，所以會出現名字沖突現象。
如：
struct CEType
{
enum EType1 { e1, e2 };
enum EType2 { e1, e2 };
};
上面的例子會出現e1、e2名字沖突編譯時錯誤，原因就在于枚舉子（e1、e2）是CEType名字空間中的名字，同樣在引用該CEType中的枚舉子時必須采用CEType::e1這樣的方式進行，而不是CEType::EType1::e1來進行引用。
注（1）POD類型：
你可以將 POD 類型看作是一種來自外太空的用綠色保護層包裝的數據類型，POD 意為“Plain Old Data”（譯者：如果一定要譯成中文，那就叫“徹頭徹尾的老數據”怎么樣！）這就是 POD 類型的含義。
其確切定義相當粗糙（參見 C++ ISO 標準），其基本意思是 POD 類型包含與 C 兼容的原始數據。
例如，結構和整型是 POD 類型，但帶有構造函數或虛擬函數的類則不是。
POD 類型沒有虛擬函數，基類，用戶定義的構造函數，拷貝構造，賦值操作符或析構函數。
為了將 POD 類型概念化，你可以通過拷貝其比特來拷貝它們。此外， POD 類型可以是非初始化的。
2. 作為一個用戶自定義的類型其所占用的內存空間是多少呢？
該問題就是sizeof( EType1 )等于多少的問題，是不是每一個用戶自定義的枚舉類型都具有相同的尺寸呢？
在大多數的32位編譯器下（如：VC++、gcc等）一個枚舉類型的尺寸其實就是一個sizeof( int )的大小，難道枚舉類型的尺寸真的就應該是int類型的尺寸嗎？
其實不是這樣的，在C++標準文檔（ISO14882）中并沒有這樣來定義，
標準中是這樣說明的：“枚舉類型的尺寸是以能夠容納最大枚舉子的值的整數的尺寸”，
同時標準中也說名了：“枚舉類型中的枚舉子的值必須要能夠用一個int類型表述”，
也就是說，枚舉類型的尺寸不能夠超過int類型的尺寸，但是是不是必須和int類型具有相同的尺寸呢？
上面的標準已經說得很清楚了，只要能夠容納最大的枚舉子的值的整數就可以了，那么就是說可以是char、short和int。
例如：
enum EType1 { e1 = CHAR_MAX };
enum EType2 { e2 = SHRT_MAX };
enum EType3 { e3 = INT_MAX };
上面的三個枚舉類型分別可以用char、short、int的內存空間進行表示，也就是：
sizeof( EType1 ) == sizeof( char );
sizeof( EType2 ) == sizeof( short );
sizeof( EType3 ) == sizeof( int );
那為什么在32位的編譯器下都會將上面三個枚舉類型的尺寸編譯成int類型的尺寸呢？
主要是從32位數據內存對其方面的要求進行考慮的，在某些計算機硬件環境下具有對齊的強制性要求（如：sun SPARC），
有些則是因為采用一個完整的32位字長CPU處理效率非常高的原因（如：IA32）。
所以不可以簡單的假設枚舉類型的尺寸就是int類型的尺寸，說不定會遇到一個編譯器為了節約內存而采用上面的處理策略。
3. 使用enum類型是否真的能夠起到有限集合常量的邊界約束呢？
首先看一下下面這個例子：
enum EType { e1 = 0, e2 };
void func1( EType e )
{
if ( e == e1 )
{
// do something
}
// do something because e != e1 must e == e2
}
void func2( EType e )
{
if ( e == e1 )
{
// do something
}
else if ( e == e2 )
{
// do something
}
}
func1( static_cast<EType>( 2 ) );
func2( static_cast<EType>( -1 ) );
上面的代碼應該很清楚的說明了這樣一種異常的情況了，在使用一個操出范圍的整型值調用func1函數時會導致函數采取不該采取的行為，而第二個函數可能會好一些他僅僅是忽略了超出范圍的值。
這就說明枚舉所定義的類型并不是一個真正強類型的有限常量集合，這樣一種條件下和將上述的兩個函數參數聲明成為整數類型沒有任何差異。所以以后要注意標準定義中枚舉類型的陷阱。
（其實只有類類型才是真正的強類型）
4. 是否真的在任何地方都可以使用enum類型的變量來代替int類型的變量呢？
通過上面的討論，其實枚舉類型的變量和整型變量具有了太多的一致性和可互換性,那么是不是在每一個可以使用int類型的地方都可以很好的用枚舉類型來替代呢？
其實也不是這樣的，畢竟枚舉類型是一個在編譯時可區分的類型，
同時第2點的分析枚舉類型不一定和int類型具有相同的尺寸，這兩個差異就決定了在某些場合是不可以使用枚舉類型來代替int類型的。
如：
第一種情況：
enum EType { e1 = 0, e2, e3 };
EType val;
std::cin >> val;
第二種情況：
enum EType { e1 = 0, e2, e3 };
EType val;
std::scanf( "%d", &val );
上面的兩種情況看是基本上屬于同一種類型的問題，其實不然。第一種情況會導致編譯時錯誤，
會因為std::cin沒有定義對應的枚舉類型的重載>>運算符而出錯，這就說明枚舉類型是一種獨立和鑒別的類型；
而第二種情況不會有任何編譯時問題，但是可能會導致scanf函數棧被破壞而使得程序運行非法，為什么會這樣呢？
上面已經分析過了枚舉類型變量的尺寸不一定和int類型相同，這樣一來我們采用%d就是說將枚舉類型變量val當作4字節的int變量來看待并進行參數壓棧，
而在某些編譯器下sizeof( val )等于1字節，這樣scanf函數就會將val變量地址中的后續的三字節地址也壓入棧中，
并對其進行賦值，也許val變量后續的三個字節的地址沒有特殊含義可以被改寫（比如是字節對齊的空地址空間），
可能會認為他不會出現錯誤，其實不然，在scanf函數調用結束后會進行棧清理，
這樣一來會導致scanf函數清理了過多的地址空間，從而破壞了外圍函數的棧指針的指向，從而必然會導致程序運行時錯誤。
由上面的說明枚舉類型有那么多的缺點，那我們怎樣才能夠有一個類型安全的枚舉類型呢？實際上，在最新的 C++0x 標準草案中有關于枚舉作用域問題的提案，但最終的解決方案會是怎樣的就無法未卜先知了，畢竟對于象 C++ 這樣使用廣泛的語言來說，任何特性的增刪和修改都必須十分小心謹慎。
當然，我們可以使用一些迂回的方法來解決這個問題（C++ 總是能給我們很多驚喜和意外）。
例如，我們可以把枚舉值放在一個結構里，并使用運算符重載來逼近枚舉的特性：
struct FileAccess {
enum __Enum {
Read = 0x1,
Write = 0x2
};
__Enum _value; // 枚舉值
FileAccess(int value = 0) : _value((__Enum)value) {}
FileAccess& operator=(int value) {
this->_value = (__Enum)value;
return *this;
}
operator int() const {
return this->_value;
}
};
我們現在可以按照希望的方式使用這個枚舉類型：
FileAccess access = FileAccess::Read;
并且，因為我們提供了到 int 類型的轉換運算符，因此在需要 int 的地方都可以使用它，例如 switch 語句：
switch (access) {
case FileAccess::Read:
break;
case FileAccess::Write:
break;
}
當然我們不愿意每次都手工編寫這樣的結構。通過使用宏，我們可以很容易做到這一點：
#define DECLARE_ENUM(E) \
struct E \
{ \
public: \
E(int value = 0) : _value((__Enum)value) { \
} \
E& operator=(int value) { \
this->_value = (__Enum)value; \
return *this; \
} \
operator int() const { \
return this->_value; \
} \
\
enum __Enum {
#define END_ENUM() \
}; \
\
private: \
__Enum _value; \
};
我們現在可以按如下的方式定義前面的枚舉，并且不比直接寫 enum 復雜多少。
DECLARE_ENUM(FileAccess)
Read = 0x1,
Write = 0x2,
END_ENUM()
DECLARE_ENUM(FileShare)
Read = 0x1,
Write = 0x2,
END_ENUM()
2009年3月11日
版權聲明：轉載時請以超鏈接形式標明文章原始出處和作者信息及本聲明
http://spelldev.blogbus.com/logs/11066253.html
關于團隊決策
轉載請注明作者和出處，如有商業用途請聯系作者kingcrimson at tom.com
目前的企業中，團隊決策已經成為一個必不可少的環節。團隊決策具有以下幾個好處：(1)信息量不斷擴大，知識隨之增長；
(2)多種不同的觀點在一起擦出更多火花；
(3)團隊成員執行時更愿意接收；
(4)眾人決策比個人決策更具有準確性、權威性、合理性；
(5)大家共同達成結論，分享和擴散責任。
迅速而有效的做出決策，是現代化企業的一個必備的要求。如何做出合理而有效的決策，如何統一團隊意見，減少分歧，是團隊決策中要面臨的首要問題。
在日常工作中，我們經常會遇到以下情景的問題：會議拖沓冗長，問題懸而未決，與會人員各抒己見，大家沒精打采，甚至發生口舌之爭……像這樣的問題，對于企業的工作進度是十分有害的。在通常的工作進度中，有數量眾多的問題需要團隊成員達成一個解決辦法。如果不能進行有效的團隊決策，將會對整個項目造成嚴重影響。
例如，長時間未解決問題，會使團隊成員的心理產生焦慮情緒，破壞他們的積極性。團隊成員會對工作環境及決策人產生質疑。時間久了，團隊的凝聚力會下降，同時工作質量也會急速下降。另一方面，迅速的解決問題，卻沒有有效的解決問題，也是對團隊工作的一個危害。比如，團隊的意見沒有達成一致，但決議已經確定。一些團隊成員找不到合理的理由來相信這種決策，他們就會在工作中不能有效的貫徹這個決議。團隊工作是一項發揮每個人的作用的工作方式，只要一個環節出了差錯，就可能會導致全盤皆負。同時，這種工作狀態也會影響到團隊配合和整體士氣。
因此，對團隊決策的要求最重要就在于“效率”。不僅要做出合理而有效的決策，還要迅速、敏捷，減少工作進度的延誤。
為了達成此目標，可以參照以下的解決方案。
首先，在進行團隊決策之前，必須存在一個主持人，或者協調者。他最好不是決策者，并且不帶有主觀意向。主持人的工作將是團隊決策的關鍵部分，貫穿于整個流程。團隊決策的工作模式，和其它工作一樣，都是按照提出問題、分析問題、解決問題的流程進行的。以下便是團隊決策的簡單流程：
明確問題，對問題進行評估。
作為發起團隊決策的主持人，在初期準備階段，必須先明確問題，對問題進行評估。主持人應該制定出問題的重要等級，以便于采取何種方式來進行團對決策。如果是一個復雜的問題，需要將問題轉化為若干的小問題，以減少決策中的復雜度。在這個階段，還要收集與問題有關的相關資料，這樣可以使決策過程更有據可循，加快決策流程。總之，準備工作做的越充分，對于之后的決策流程是越有利的。
制定合理的決策人選。
這個步驟也是非常重要的。對于主持人來說，他可能不具備制定人選的權力。（這部分一般是顯而易見的或者由團隊領導來決定）但是主持人可以對決策人選進行編排和搭配。一般對于小規模的團隊，問題可能不是很大。但是大規模的團隊，如果不進行合理的編排，將會使決策過程的變得混亂而拖沓。這里，可以采取幾個有效的方式來編排決策人員。比如，按職能劃分，按個人對于問題的重要程度劃分等。常見的做法是，把一個大的團隊劃分成若干小組，每個小組盡可能達成一致意見，最后再統一達成決策。
選擇合適的決策方式。
一般的決策方式就是會議。不管是何種類型的會議，都是決策過程中必不可少的過程。作為主持人，需要制定用何種方式來進行會議。以下有一些可以參考的方式：
1. 頭腦風暴法
頭腦風暴法的一般步驟：
(1)所有的人無拘無束提意見，越多越好，越多越受歡迎。
(2)通過頭腦風暴產生點子，把它公布出來，供大家參考，讓大家受啟發。
(3)鼓勵結合他人的想法提出新的構想。
(4)與會者不分職位高低，都是團隊成員，平等議事。
(5)不允許在點子匯集階段評價某個點子的好壞，也不許反駁別人的意見。
研究表明，大家在無拘無束、相互激蕩的情形下匯集的點子往往比一般方法所匯集的點子多70%。
2. 德爾菲法
德爾菲法又叫專家群體決策法，就是由一群專家來達成團隊的決策。
(1)德爾菲法的特點
讓專家以匿名群眾的身份參與問題的解決，有專門的工作小組通過信函的方式進行交流，避免大家面對面討論帶來消極的影響。
(2)德爾菲法的一般步驟
①由工作小組確定問題的內容，并設計一系列征詢解決問題的調查表；
②將調查表寄給專家，請他們提供解決問題的意見和思路，專家間不溝通，相互保密；
③專家開始填寫自己的意見和想法，并把它寄回給工作小組；
④處理這一輪征詢的意見，找出共同點和各種意見的統計分析情況；將統計結果再次返還專家，專家結合他人意見和想法，修改自己的意見并說明原因；
⑤將修改過的意見進行綜合處理再寄給專家，這樣反復幾次，直到獲得滿意答案。
德爾菲法用于團隊決策可以進行一些變通：比方說將專家換成團隊成員、加入外部專家、為了減少成本，提高效率可以不采取信函方式，而直接溝通。
3. 異地思考法
異地思考法就是讓團隊離開原來的工作環境，擺脫日常事物的干擾，到另外的地方進行專門研究。比方說企業領導把管理人員和專業技術人員請到鄉村別墅，住上兩天，專門研究企業發展中出現的重大問題。讓參與決策的人離開辦公室，到一個新的環境討論問題，使他們擺脫工作環境中上下級界限的問題，隔離繁瑣事情的干擾。由于大家暢所欲言、思想活躍，就可以提出一種高水平的構想，最后做出高水平的決策。
這些方式只是簡單的模板或示例。不管采用哪一種方法。對于主持人來說，必須做到：組織良好的決策流程，控制決策流程的實施，協調決策過程中的氣氛。
整理決議，結束決策過程。
這個步驟是一個關鍵，標志著決策的成形。在團隊決策中，一般會存在一個最終決策人的角色。他可能是團隊的領導，或者是這個問題的最大成分負責人。而主持人的工作，就要協調好最終決策人和團隊成員的關系，并輔佐最終決策人做出決策。最終決策人對于問題有自己的意見，同時他也可能是問題解決方案的最終制定者。為了避免最終決策人對團隊決策造成不利的影響，比如團隊成員因為某些原因不愿或不敢發表自己的意見，主持人需要控制好最終決策人的參與方式。這需要注意幾個問題：
1. 不要讓最終決策人過早的參與到團隊決策中。這并不時是說在時間方面，而是不要讓最終決策人的意見干涉到團隊成員制定決策的過程。如果最終決策人過早的給出了自己的意見，其它團隊成員可能會被限制住思考的界限，或者失去決策的動力。
2. 不要讓最終決策人與問題分離太遠。作為最終決策人，必須付出比團隊成員更多的精力去了解問題和分析問題，才能保證決策的正確實施。如果對問題了解不充分，會使團隊成員對最終決策產生懷疑和抵觸。
3. 明確責任承擔方式。這是團隊決策中一個敏感部分。主持人和最終決策人必須制定出合理的責任承擔方式，并告知團隊成員。這個過程可能比較艱難，但一定要評估出決策帶來的風險，并制定出后續的解決方案，盡量使風險帶來的損失減少到最小。
以上便是團隊決策一個簡單流程。真正的實施，還要根據具體情況做出合理的應用和變化。團隊決策中，會面臨著很多問題，使團隊決策變得艱難而緩慢。其中最容易出現的兩個誤區，就是團隊偏極（group polarization）和集一思考（groupthink）。
團隊偏極是指團隊的綜合決策偏向極端化。1961年，美國麻省理工大學做過一項研究，分兩階段進行：第一階段是問卷方式調查工業屆從業人員對某些后果不確定問題的態度。第二階段是邀請受調查者出席一場座談會，要他們面對調查問卷上同樣的問題，并做出決策。最后比較兩階段的決策時發現團體決策遠較個人決策為極端，個人決策比較謹慎，團體決策比較冒險。后來又經過心理學家反復研究發現團體決策具有極端化傾向，但是極端化的方向不僅限于冒險激進的一端，而是也可能出現在謹慎保守的另一端。如果團體成員多數是屬于冒險激進分子，那么他們所做出的決策就會更為冒險激進，如果團體成員多數屬于謹慎保守者，那么他們所做出的決策就會更為謹慎保守。團體偏極的現象在社會生活中是很常見的。社會上有不同團體社團，有的保守，有的激進，經常可見的現象是你與保守派中的個人接觸，他未必保守，你與激進派中個人接觸，他未必激進，可是一經團體決策，就馬上體現出很強的保守或激進性了。所以現在很多人回想起當年文化大革命中做紅衛兵的一些經歷，怎么都不會相信，以自己的個性當年會做出那么離譜的事情，這大體也是因為團體決策的關系。
對于團隊偏極的另一個解釋是是：參與決策者由于生怕被別人認為自己是極端主義者，個人在決策時往往會回避一些自己認為是比較理想（極端）的立場。然而在小組討論各成員將自己個人看法與其他人的立場比較時，會發現別人的意見更加接近于自己心目中的理想，也就是說可能聽到別人所持的理由更優于自己。這種發現加重了他自己態度上原本極端的程度，促使他（她）改變原先決定而選擇相比之下更加理想（極端）的決定，從而整體上使意見更加偏向極端。
相對于團隊偏極，集一思考的害處更大。所謂的集一思考是指某項團隊決策是在全體成員毫無異議的情況下達成的。本來任何問題的取決或多或少都會有所爭議，就事而言有利有弊，就人而言，見仁見智。總不至于團體討論時全數通過毫無疑義。但是集一思考這種現象是確實存在的，專政社會里集一思考不足為奇怪，這里就不列舉了，但是像美國這樣的民主社會，也還是屢見不鮮，甚至往往還是牽涉到國家興亡的大事。比如1942年羅斯福總統任內的日軍偷襲珍珠港事件，1961年肯尼迪總統任內秘密訂立的突襲古巴豬玀灣方案，甚至1972年尼克松總統任內的水門事件無一不是有智囊團所作的團隊決策所致。
由于要取得意見一致的壓力太大從而壓制了決策成員對行動計劃的客觀評估的思維方式。由于要努力地維護團隊的凝聚力和取得意見一致，成員們不自覺地放棄了挑剔的想法和對行動計劃的優缺點進行檢討。然而所放棄的恰恰是科學決策的必須過程。因此“集一思考”的典型結果就是考慮不周的決定。
在四種處境下“集一思考”發生的可能性比較大：危機處境，高度團結的團隊，缺乏局外人的判斷和檢視，以及過于強調自己意見的團隊領導。
要避以上兩個誤區，需要團隊決策主持人嚴謹的貫徹團隊決策流程，并制定出面對問題的不同解決方案。主持人可以在團隊決策進行前，進行幾次假想的模擬或試驗，考慮到不同問題出現的可能性，并制定出相應的解決辦法。并且在團隊決策進行中，主持人可以根據不同的情形，對決策過程進行相應的調整。
綜上所述，團隊決策是一項技術，也是一門藝術。以上只是關于團隊決策的一個籠統的概述和討論。不管采用何種方式，對團隊決策高度重視并有效的控制，將是企業創造高效率工作方式的資本。
King Lee
2007-1-14
2008年12月24日
調試快捷鍵
F6: 生成解決方案
Ctrl+F6: 生成當前項目
F7: 查看代碼
Shift+F7: 查看窗體設計器
F5: 啟動調試
Ctrl+F5: 開始執行(不調試)
Shift+F5: 停止調試
Ctrl+Shift+F5: 重啟調試
F9: 切換斷點
Ctrl+F9: 啟用/停止斷點
Ctrl+Shift+F9: 刪除全部斷點
F10: 逐過程
Ctrl+F10: 運行到光標處
F11: 逐語句
編輯快捷鍵Shift+Alt+Enter: 切換全屏編輯
Ctrl+B,T / Ctrl+K,K: 切換書簽開關
Ctrl+B,N / Ctrl+K,N: 移動到下一書簽
Ctrl+B,P: 移動到上一書簽
Ctrl+B,C: 清除全部標簽
Ctrl+I: 漸進式搜索
Ctrl+Shift+I: 反向漸進式搜索
Ctrl+F: 查找
Ctrl+Shift+F: 在文件中查找
F3: 查找下一個
Shift+F3: 查找上一個
Ctrl+H: 替換
Ctrl+Shift+H: 在文件中替換
Alt+F12: 查找符號(列出所有查找結果)
Ctrl+Shift+V: 剪貼板循環
Ctrl+左右箭頭鍵: 一次可以移動一個單詞
Ctrl+上下箭頭鍵: 滾動代碼屏幕，但不移動光標位置。
Ctrl+Shift+L: 刪除當前行
Ctrl+M,M: 隱藏或展開當前嵌套的折疊狀態
Ctrl+M,L: 將所有過程設置為相同的隱藏或展開狀態
Ctrl+M,P: 停止大綱顯示
Ctrl+E,S: 查看空白
Ctrl+E,W: 自動換行
Ctrl+G: 轉到指定行
Shift+Alt+箭頭鍵: 選擇矩形文本
Alt+鼠標左按鈕: 選擇矩形文本
Ctrl+Shift+U: 全部變為大寫
Ctrl+U: 全部變為小寫
代碼快捷鍵Ctrl+J / Ctrl+K,L: 列出成員
Ctrl+Shift+空格鍵 / Ctrl+K,P: 參數信息
Ctrl+K,I: 快速信息
Ctrl+E,C / Ctrl+K,C: 注釋選定內容
Ctrl+E,U / Ctrl+K,U: 取消選定注釋內容
Ctrl+K,M: 生成方法存根
Ctrl+K,X: 插入代碼段
Ctrl+K,S: 插入外側代碼
F12: 轉到所調用過程或變量的定義
窗口快捷鍵Ctrl+W,W: 瀏覽器窗口
Ctrl+W,S: 解決方案管理器
Ctrl+W,C: 類視圖
Ctrl+W,E: 錯誤列表
Ctrl+W,O: 輸出視圖
Ctrl+W,P: 屬性窗口
Ctrl+W,T: 任務列表
Ctrl+W,X: 工具箱
Ctrl+W,B: 書簽窗口
Ctrl+W,U: 文檔大綱
Ctrl+D,B: 斷點窗口
Ctrl+D,I: 即時窗口
Ctrl+Tab: 活動窗體切換
Ctrl+Shift+N: 新建項目
Ctrl+Shift+O: 打開項目
Ctrl+Shift+S: 全部保存
Shift+Alt+C: 新建類
Ctrl+Shift+A: 新建項
F5是用調試模式運行,對于程序拋出的異常會進行檢查的,有些異常調試器會忽略,有些異常會談出對話框。哪些異常忽略，哪些談出對話框是可以設置的。
Ctrl+F5是直接運行程序，調試器完全不管程序運行狀態，所以所有未被俘獲的異常都回導致程序直接退出。
2008年11月22日
摘要: ### 簡介 ###
log4cplus是C++編寫的開源的日志系統，前身是java編寫的log4j系統.受Apache Software License保護。作者是Tad E. Smith。log4cplus具有線程安全、靈活、以及多粒度控制的特點，通過將信息劃分優先級使其可以面向程序調試、運行、測試、和維護等全生命周期； 你可以選擇將信息輸出到屏幕、文件、NT event log、甚至是遠程...
閱讀全文
2008年11月14日
斷言：
ASSERT_TRUE(condition); EXPECT_TRUE(condition); condition為真
ASSERT_FALSE(condition); EXPECT_FALSE(condition); condition為假
ASSERT_EQ(expected, actual); EXPECT_EQ(expected, actual); expected == actual
ASSERT_NE(val1, val2); EXPECT_NE(val1, val2); val1 != val2
ASSERT_LT(val1, val2); EXPECT_LT(val1, val2); val1 < val2
ASSERT_LE(val1, val2); EXPECT_LE(val1, val2); val1 <= val2
ASSERT_GT(val1, val2); EXPECT_GT(val1, val2); val1 > val2
ASSERT_GE(val1, val2); EXPECT_GE(val1, val2); val1 >= val2
ASSERT_STREQ(expected_str, actual_str); EXPECT_STREQ(expected_str, actual_str); 兩個C字符串有相同的內容
ASSERT_STRNE(str1, str2); EXPECT_STRNE(str1, str2); 兩個C字符串有不同的內容
ASSERT_STRCASEEQ(expected_str, actual_str); EXPECT_STRCASEEQ(expected_str, actual_str); 兩個C字符串有相同的內容，忽略大小寫
ASSERT_STRCASENE(str1, str2); EXPECT_STRCASENE(str1, str2); 兩個C字符串有不同的內容，忽略大小寫
ASSERT_*版本的斷言失敗時會產生致命失敗，并結束當前函數。EXPECT_*版本的斷言產生非致命失敗，而不會中止當前函數。通常更推薦使用EXPECT_*斷言，因為它們運行一個測試中可以有不止一個的錯誤被報告出來。但如果在編寫斷言如果失敗，就沒有必要繼續往下執行的測試時，你應該使用ASSERT_*斷言。
因為失敗的ASSERT_*斷言會立刻從當前的函數返回，可能會跳過其后的一些的清潔代碼，這樣也許會導致空間泄漏。根據泄漏本身的特質，這種情況也許值得修復，也可能不值得我們關心——所以，如果你得到斷言錯誤的同時，還得到了一個堆檢查的錯誤，記住上面我們所說的這一點。
要提供一個自定義的錯誤消息，只需要使用<<操作符，或一個<<操作符的序列，將其輸入到框架定義的宏中。下面是一個例子：
ASSERT_EQ(x.size(), y.size()) << "Vectors x and y are of unequal length";
for (int i = 0; i < x.size(); ++i) {
EXPECT_EQ(x[i], y[i]) << "Vectors x and y differ at index " << i;
}
任何能夠被輸出到ostream中的信息都可以被輸出到一個斷言宏中——特別是C字符串和string對象。如果一個寬字符串（wchar_t*，windows上UNICODE模式TCHAR*或std::wstring）被輸出到一個斷言中，在打印時它會被轉換成UTF-8編碼。
如果需要將信息輸出到XML中。在參數中使用：
--gtest_output=xml:test.xml
就可以了