總結的不錯

羨慕死人了，我07年才開始接觸電腦編程。

堅強起來，做出點成績給父親看看。讓他放心。

@viewer
腳本你編譯了嗎？你是用all的那個工程嗎？

goodjob

@viewer
mapviewer
http://wowmapviewer.googlecode.com/svn/trunk
modelviewer
http://wowmodelviewer.googlecode.com/svn/trunk

goodjob

@sqd
要用 svn工具下載

@sqd
這個還是比較穩定的，可以下載下來，測試看看，據說很多商業的sf都是用這個做的。

@xiao_liang
好像不行吧，一般放在cpp的東西都是運行時實現，而模板類或模板函數的實現內容是對某一類型的抽象實現。實現還不存在，在編譯的過程中才會發現需要哪些具體類型的運行時實現。

@xx
你對mangos，那些地方懷疑，方便說下嘛？

@xx
這個效率相對來說還是比較高，最起碼比mangos高。

@xx
據說單臺千人左右。

次級的程序員不懂oo，還老說oo沒用。
初級的程序員了解了oo，亂用oo。
中級的程序員理解了oo，用的恰到好處。
高級的程序員心中有oo，卻不愿表現出oo來。
神級的程序員完全不懂oo，他用計算機思維解決問題。

程序員分兩種：天賦異秉的，渾渾噩噩的。

去看boost的模板元吧。比loki舒服

gluPerspective，gluOrtho，這些都是通過傳入的那些參數，變換成一個矩陣，這個矩陣可以叫投影矩陣。gluPerspective表示投射投影，gluOrtho正交投影。理解的不錯。

so cool 未來的軟件大師。

好樣的，一起學習。

qsort
實現的太過簡單。。。。。。沒啥實際價值。

@foxriver
是的，旋轉不還是保證了方向性，而沒有保證他的位置性嗎？

作者對面向對象的思想理解深刻，面向對象并不一定要用c++，java，c#寫。c依然可以寫出漂亮的面向對象來（這點我從linux源碼中發現，而且它的面向對象抽象基本是零消耗的，但需要很深厚的功底來完成一些技巧），面向對象很好理解，程序的本質還是過程式，所以要把握住對象構造到析構的主干線，理解軟件體系中的線程模型。而且對象的抽象要多加思考，是否真的需要抽象這類對象，抽象這類對象是為了什么？能否用聚合組合來替代？過于臃腫的類體系結構擴展性受到影響，而且會增大對象占用空間，明白什么時候upcast，什么時候downcast。好的面向對象抽象一樣可以提高效率，而且有時候用好c++效率還會比c高（因為在真正代碼執行期間，cpu通過ecx知道c++的類對象上下文），盡量減少或避免虛表重復查找次數。面向對象是一潭深水啊，掉進去一定要出來。

不是每個人都明白奮斗是什么？就

這個每個做程序的，都是這么想的吧？

架構師不只是用uml去畫圖，也要考慮代碼實現，架構師已死不合理，該死的是畫出來亂七八糟看似容易而自己不能卻妄想別人為他實現的架構師。這種架構師自認為讀過二年書，思維比人靈活，實際則飯桶一個。

不過這個改進比較擔心。隨機數一次多少指令？
首要做的可能是把遞歸算法改成非遞歸的。
針對元素低于8個的時候，用插入排序。
下面就是盡可能地讓分區平衡。
一個好的快速太難了。

第一題答案對嗎？#define Max(a,b) (a/b)?a:b
a = -2, b = -1
這個問題不是這么簡單的吧。
考慮到正負數，考慮到無符號情況

gimp用的不咋地啊。

good job!!

good job!!!

good job!! recently, referring to mit's introduction to algorithms. just for basic.

bjam --toolset=msvc-8.0 --link=static --runtime-link=dynamic --threading=multi --with-system --with-regex stage

it's ok

bjam use 3.1.7 ver

我做過，而且在d3d里實現了directshow和cegui界面共同顯示。

這些東西沒必要去玩，純粹是瞎胡鬧，看到這樣做做的代碼，只能丟下句：寫這樣代碼的人，只能去當老師。

不同意，沒看完你的文章。因為你沒理解真正的協作。矛盾是進步的源泉，并不一定，觀點完全是你提出的，完全就是你一個人的戰場。戰場上除了需要純粹浴血奮戰，還需要戰略方針，衣食住行，甚至敵我間諜。
隊伍不能協作好，只可能是水平參差不齊，目標不統一，內憂外患。

good!!!

bu cuo

不如專門抽象出一個抽象類，比如StateMachine，然后Player持有StateMachine的指針來控制Player的狀態切換。

我感覺你這樣沒有拓展性，用fsm來更好點，首先對于player來說，應該是從GameObject泛化而來的。

用ogre開發不是那么簡單的，我感覺，ogre只給你提供了圖形渲染引擎，如果你要使用ogre進行游戲開發，就必須對ogre進行封裝，而封裝的過程你還需要游戲運行環境，游戲對象屬性、操縱方法、事件處理等，數據序列化，如果要是mmo的話，你可能還需要對仿真模擬，進程間通信，線程模型等做一系列工作。
如果用xna的話，說實話，沒用過xna，c#是動態語言，需要運行時支持效率不知道如何？但是我想微軟既然推出他，效率這方面就不需要特別考慮。
反正做游戲不是那么簡單的，不管用xna還是ogre，但是我相信用xna比用ogre來的簡單，就算你沒學過c#。

很受鼓舞。我也比較喜歡李小龍。