頂！

#include <stdio.h>
int main()
{
getchar();
return 0;
}

兄弟，面對現實吧，你不適合上學，趕快找點能做出成績的行業，開始起步吧。
比如利用你語言上的優勢，在兩國互通有無，或者復制一個國家的商機到另一個國家，或者為在國外的留學生小團體提供一些服務，常見的就是跨國話務之類的。

我的經歷也是如此，也思考過原因：
（1）公司不重技術、重市場。而開發的直接領導也是同樣的浮躁心態。
（2）開發團隊沒有技術積累、沒有統一認可的基礎架構。
（3）開發人員由于不同的開發經歷，各自有自己的基礎模塊實現、對系統有自己的認知。

改善這個情況，開發人員的角度 也只能是多溝通、互相分享知識、定期分析已有系統的架構、爭取能對同類型的應用應該使用的最佳設計達成共識。
根本解決還在領導層對技術的重視，重視基礎模塊積累、重視對系統框架的探討分析，重視團隊技術上的可持續成長。

博主好文采！
來搞技術，可惜了。

Ogre + C++吧 熟悉的話，可以直接進入實質的東西。時間都是浪費在實際的邏輯上，不是單純的工具上，如果你對工具熟悉。

如果準備時間充足，也可以考慮XNA+.NET，事先增加技術預研階段，寫預研文檔，掃平技術上的障礙，之后再進入實際的開發。

@yshuise
你確信你看懂它的實現了？

.............................
內存檢測工具跑一遍就能發現的問題，你還真執著啊。

由于內存問題宕掉，堆棧什么的都是不可信的，一定要在初次出現問題的地方找（第一次寫內存錯誤），都到后面了，什么意義都沒了。

寫完代碼，需要用內存測試工具跑反復的跑，壓力下跑，一遍沒跑期望沒有任何的內存問題 基本是不可能的。至少至今我開發的服務器，沒有一個是寫完編譯過，就沒有任何內存問題的。

@Chuck
發布到首頁的 就是要給別人分享的。很多人訂閱首頁，讓別人看不懂或者看了無所收獲的文章，也是浪費別人的時間。
如果是給自己看的，不必選擇發布到首頁。

@陳梓瀚(vczh)
其實我移出首頁的出發點,不是因為它沒開源,根本原因是我認為不能共享到任何的思想, 沒有看到可以分享的東西,當然可能是個人眼界的限制.

總上所述, 如果博主認為本文滿足“分享知識給喜歡思考并研究的人”,請重新發布到首頁吧. 我個人仍然堅持以前的看法.

@陳梓瀚(vczh)
1 luckyScript并未開源
2 本文展示了用luckyScript寫的一個計算器,以及給出運行的結果貼圖證明腳本的正確性.
3 博主并未明確說明,是來接受批評的 也未給出需要大家提出意見的方向
4 我的理解blog是分享知識的,尤其是首頁精華,訂閱首頁文章的人 更多的是希望能獲取到知識. 如果有疑惑需要大家解答,更好的選擇是發布到論壇.

偶爾往首頁發個解題報告也無不可 大量的發而又重復的沒啥意義吧
是不是可以寫的總結啊 算法基礎 npc綜述之類的發到首頁啊

發首頁 純炫耀 鑒定完畢！ 移除

頂下！

已閱 移除

removed by cppexplore

已閱 刪之

已閱 刪之

無內容。移除

博主將文章 發往首頁精華的 時候 稍微斟酌下 尤其是很多篇一起放上來的時候，沒多少時間一篇一篇的審核，多謝。

博主放到sf上吧，配上英文說明、文檔等。有時候99％和100％就是差那么一點額外的努力。

頂博主
多發寫相關的東西啊
坐下來慢慢看

@OwnWaterloo
上班不能qq 呵呵 下班加你
A不能以指定消息值的方式向B發消息，通過調用B自身的ON_MSG方法發送。也就是除了B自己，誰也不知道它具體消息的枚舉值。
64一下的也是調用B自身的方法發送，不過這些是B基類中的方法。

@OwnWaterloo
不是同一套，只有64以下的是相同。64以上的各個線程之間可以重復，因為對其他對象是不可見得，所以不存在沖突問題。可以定義USER_MSG_START=64.
項目越大，越需要表格，容易維護，容易擴展，容易找對應關系，也就是看一個文件就知道所有，而不是在幾十個上百個文件里查找。當然要看你的虛函數實現成什么樣子了。
我舉的例子，對象B是管理類，同時也是線程類。里面管理了很多的對象，B拿到消息也是找到對應的對象去處理，貌似你一直談的是后續。
而你在MFC里看到的是同一套，那是因為它們都在UI線程里，同屬于一個線程，一個管理類。

樓上的各位啊 歡迎來討論理論或者思想 具體到代碼細節的東西就免了，文章已經很詳細很詳細了。

@sashion
不曉的啊，可以去看源代碼 ：）

@OwnWaterloo
呵呵 你覺得你的想法來源于面向對象的紙上談兵（沒有貶義）以及基于win32的mfc框架程序設計。
我的實現不是為了模擬虛函數的實現，只是為了實現一個易維護的消息映射而已。
首先 對象A不能直接向對象B直接發送消息，需要調用對象B的ON_send_msg，由B自己的方法向自己發送消息，由B的DO_Msg方法處理消息，當然發送動作和處理動作在不同的線程內。任何對象向B發送消息都要調用B自己的方法。也就是說對象B的具體消息類型對其它對象是不可見的。
因此對象B中的消息類型是連續的，并且不存在自己不感興趣的消息，既然不感興趣，就不會存在這個消息類型，只要是存在的就是感興趣的，就是要處理的。也不存在對多個消息，處理方式相同的問題，既然處理方式相同，它們就是同一個消息。
其次 你還是回避了大型程序開發中，使用虛函數方式，文件個數膨脹的問題。
最后 我討論的是線程間的消息傳遞和映射，你的有偏向于 已經發送到UI線程的消息，對責任鏈模式上的 各個對象的后續處理。

@OwnWaterloo
呵呵，最后的問題歸結為：哪種更容易理解和擴展。
超大工程當然是數組方式之上用宏展現最容易理解和擴展了，簡潔直接。幾十w行的代碼，用虛函數，文件數量的迅速膨脹 找個東西都找不到在哪里，所有東西交織錯亂在一起，最終維護程序的人都會想：要是有張表就好了，只看表就知道那個函數處理哪個消息，而宏的展現就是如此。 當然如果用宏包裹下虛函數的實現，結果就一樣了。
并且數組表只是一個思路，不攜帶任何面向對象的語義，在這個業務系統里可用，在那個業務系統里也可用，虛函數有這么好的移植性嗎？有這么簡單化嗎？

@OwnWaterloo
怎么不直接去我blog回復呢 呵呵
其實 時間消耗 之類并不是我最得意的東西，這種實現的細節 我并不太關注，所以質疑你以前說的 “虛函數占用較多資源而導致不得已采用消息路由”，如何實現并不重要，關鍵的是容易理解，容易擴展，容易維護，容易移植，容易簡單化。
win32 你是指win32 的界面設計？ 業務系統里 基本不同的消息有不同的實現，我的本意其實都不在實現，而在于簡單的思想，因此是查表實現 還是虛函數實現 也都無所謂，只要最后有統一的擴展方式。

@OwnWaterloo
歡迎來我blog討論：http://m.shnenglu.com/CppExplore 這篇http://m.shnenglu.com/CppExplore/archive/2008/11/07/66216.html下。查表是本質，為什么要使用虛函數？更容易理解?MFC的消息映射展現方式很難理解嗎？ 虛函數更容易擴展嗎？ 說到虛函數占用較多資源而導致不得已采用消息路由，我不能認同，這個因素在整個系統中的開銷你有沒有量化過？比如 因為采用它導致并發數下降了多少多少之類？歡迎來我blog討論。

1. 都為欠缺開發經驗的應屆畢業生
培訓、溝通、討論
2. 沒有做完善的詳細設計，需求分析完后立即開發，導致后期頻繁改變系統架構，延遲開發時間
-->需求文檔、review需求文檔
開發文檔、review開發文檔
3. 沒有模塊做單元測試
-->培訓
4. 沒有 code review
-->問題不是很大，可以兩兩review 互相學習
5. 代碼覆蓋率 < 10%
-->一和代碼架構有關 學習、總結、討論
二和測試方式有關 培訓
6. 開發小組提交到時測試小組前，沒有做內部測試，導致很多產品被測試小組打回
-->寫測試文檔，培訓測試流程、方式 評估bug個數 代碼可讀性 作為個人績效考評依據

7. 測試小組目前只做黑盒測試，很多BUG測不出或難以重現，導致產品在正式投入使用后出現很多問題

-->到測試組前，需要研發做白盒測試。測試小組拿到產品前，根據需求文檔寫測試項。愈是代碼行數多的模塊，所做的測試項愈多
8. 沒有完善的版本管理，從客戶那邊拿回來產品經常找不到對應的源代碼
-->指定項目經理，對項目負責，可以調度研發人員、測試人員等資源。另安排專門的人做it文檔、版本等管理。

總之 應屆生有激情，給予相應的指導培訓、制度化、多鼓勵、多總結，一切會好起來的。

樓主 要不要聘請一個兼職顧問，提供一下培訓啊，呵呵。
另 removed

@LOGOS
呵呵。誰能想到答案在23種模式之外呢。不過理解mvc的關鍵是observer，不是那個browser。也難說你從另一個特別的角度同樣了理解了mvc的關鍵所在。：）

多年不回顧專業課了。去《Design Patterns》里復制點原話出來：第五章 行為模式的observer模式中的Know Uses部分：
The first and perhaps best-known example of the Observer pattern appears in Smalltalk Model/View/Controller (MVC), the user interface framework in the Smalltalk environment [KP88]. MVC's Model class plays the role ofSubject, while View is the base class for observers.
當年專業課考試，題目是圖形的場景，我答observer，標準答案mvc,老師給零分，郁悶。

@LOGOS
mvc并不是23種設計模式的任意一種。
它是設計圖形交互系統的常用方式。它引入了龐大的應用場景，當然往大了說，可以說它是一種框架，往小了說，它接近哪個模式呢？

每個模式都是一種思想，而不是簡單的固定實現。observer描述的是觀察者 被觀察者之間 的notify和update行為，如果用這個模式來實現ui交互，應該是什么樣子呢？

先理解了observer模式，再理解mvc就容易了，mvc可以說是observer的特例

.................................
真的沒人愿意看看RAII???????????????guard的實現、資源的自動管理、資源申請的原子操作？？？？這個題目也只是RAII的一個小小實踐
class X{
public:
X(){}
~X(){printf("hello world!\n");}
};
int main()
{
X obj[n];
return 0;
}

汗，上個評論最后一句多寫了一個“不”，博主見諒。

我想樓主想表達的意思并不在于該題本身，而是RAII
我隨意搜索了一下，有興趣可以繼續看下：http://hi.baidu.com/joel%5Ftan/blog/item/8682fcd8ceefeb3032fa1c3b.html
相信大家不會認為博主的這點“簡單”想法不是“nosense”。

不錯，很好的思路。
樓上各位需要明白下 空杯心理。

@ssharry
其它線程快速調用putq兩次，如果有2個線程在getq處阻塞，就會被同時激活，而完全有可能，其中一個被激活的線程獲取到了cpu，快速處理了2個消息。

呵呵，有一句話說的很好：
心中有佛看到的便是佛,心中有屎看到的便是屎。
不要胡亂猜測別人是裝逼犯哦。

@ssharry
可能是吧。這篇文章里東西都沒實用的價值，就是理論上想象一下而已，呵呵。http://m.shnenglu.com/CppExplore/archive/2008/03/20/44949.html這個里面的才是實際可用的。

熬夜很傷肝啊 還是早睡早起好習慣 呵呵

@田伯光
log4cplus是線程安全的。多進程共享內存的方式使用對象，和多線程的方式是一樣的。你可以壓力下測試下，呵呵。
另外，打印到syslogd和打印到socket也是多進程打印log的備選方案。
log系統用開源也不是因為它們功能強大，主要的好處是它們充分考慮了IO輸出的效率（開辟內存池，延遲批量輸出），第二個是系統宕掉時候，log打印的準確性。另外用宏隔離，也方便以后發現更好log系統時候替換。

@kacy16
：）

@田伯光
呵呵，多進程一定不能共享對象，除非這個對象在共享內存中，共享內存中的對象又要注意互斥問題。最好的辦法還是各進程用自己的進程的log對象。運行期間動態改變log的級別，可以去代碼中找答案，或者你等我有了這個需求，我改好告訴你，呵呵。

@dxzhan
非常高興有人喜歡我的blog。
您的回帖是我繼續的最大動力，呵呵。

一句話，多用組合，少用繼承。