CppExplore

頂！

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

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

我的經(jīng)歷也是如此，也思考過原因：
（1）公司不重技術(shù)、重市場。而開發(fā)的直接領(lǐng)導(dǎo)也是同樣的浮躁心態(tài)。
（2）開發(fā)團隊沒有技術(shù)積累、沒有統(tǒng)一認(rèn)可的基礎(chǔ)架構(gòu)。
（3）開發(fā)人員由于不同的開發(fā)經(jīng)歷，各自有自己的基礎(chǔ)模塊實現(xiàn)、對系統(tǒng)有自己的認(rèn)知。

改善這個情況，開發(fā)人員的角度 也只能是多溝通、互相分享知識、定期分析已有系統(tǒng)的架構(gòu)、爭取能對同類型的應(yīng)用應(yīng)該使用的最佳設(shè)計達(dá)成共識。
根本解決還在領(lǐng)導(dǎo)層對技術(shù)的重視，重視基礎(chǔ)模塊積累、重視對系統(tǒng)框架的探討分析，重視團隊技術(shù)上的可持續(xù)成長。

博主好文采！
來搞技術(shù)，可惜了。

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

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

@yshuise
你確信你看懂它的實現(xiàn)了？

.............................
內(nèi)存檢測工具跑一遍就能發(fā)現(xiàn)的問題，你還真執(zhí)著啊。

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

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

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

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

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

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

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

發(fā)首頁 純炫耀 鑒定完畢！ 移除

頂下！

已閱 移除

removed by cppexplore

已閱 刪之

已閱 刪之

無內(nèi)容。移除

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

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

頂博主
多發(fā)寫相關(guān)的東西啊
坐下來慢慢看

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

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

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

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

@OwnWaterloo
呵呵 你覺得你的想法來源于面向?qū)ο蟮募埳险劚]有貶義）以及基于win32的mfc框架程序設(shè)計。
我的實現(xiàn)不是為了模擬虛函數(shù)的實現(xiàn)，只是為了實現(xiàn)一個易維護的消息映射而已。
首先 對象A不能直接向?qū)ο驜直接發(fā)送消息，需要調(diào)用對象B的ON_send_msg，由B自己的方法向自己發(fā)送消息，由B的DO_Msg方法處理消息，當(dāng)然發(fā)送動作和處理動作在不同的線程內(nèi)。任何對象向B發(fā)送消息都要調(diào)用B自己的方法。也就是說對象B的具體消息類型對其它對象是不可見的。
因此對象B中的消息類型是連續(xù)的，并且不存在自己不感興趣的消息，既然不感興趣，就不會存在這個消息類型，只要是存在的就是感興趣的，就是要處理的。也不存在對多個消息，處理方式相同的問題，既然處理方式相同，它們就是同一個消息。
其次 你還是回避了大型程序開發(fā)中，使用虛函數(shù)方式，文件個數(shù)膨脹的問題。
最后 我討論的是線程間的消息傳遞和映射，你的有偏向于 已經(jīng)發(fā)送到UI線程的消息，對責(zé)任鏈模式上的 各個對象的后續(xù)處理。

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

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

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

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

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

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

總之 應(yīng)屆生有激情，給予相應(yīng)的指導(dǎo)培訓(xùn)、制度化、多鼓勵、多總結(jié)，一切會好起來的。

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

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

多年不回顧專業(yè)課了。去《Design Patterns》里復(fù)制點原話出來：第五章 行為模式的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.
當(dāng)年專業(yè)課考試，題目是圖形的場景，我答observer，標(biāo)準(zhǔn)答案mvc,老師給零分，郁悶。

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

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

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

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

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

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

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

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

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

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

熬夜很傷肝啊 還是早睡早起好習(xí)慣 呵呵

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

@kacy16
：）

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

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

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