說明一下 monkeyispig.com 是本人自己的blog，發(fā)在cppblog只為增加人氣 ：）所以沒有全文轉(zhuǎn)載，轉(zhuǎn)個(gè)引子請(qǐng)大家點(diǎn)擊一下：

     摘要: 新手在剛接觸一些實(shí)際項(xiàng)目的遺留代碼時(shí)會(huì)覺得很迷茫（比如我）。相信過來人都知道這種感受——代碼量大、注釋少、難讀懂。這只是最膚淺的認(rèn)識(shí)，隨著接手任務(wù)需要在代碼上做添加和修改的時(shí)候那就真的是更難以下手了。一方面是對(duì)代碼不熟悉，另一方面則是代碼已經(jīng)被修修補(bǔ)補(bǔ)得十分混亂了。  閱讀全文

     摘要: 場(chǎng)景管理是游戲中非常重要和基礎(chǔ)的部分，初次接觸場(chǎng)景管理是使用了Ogre中的場(chǎng)景管理器(SceneManager)。其中的場(chǎng)景節(jié)點(diǎn)(SceneNode)便是非常好用的一套用于表示場(chǎng)景位置關(guān)系的抽象。縱觀Ogre的實(shí)現(xiàn)，SceneNode是繼承與Node類，Node類則主要實(shí)現(xiàn)了空間位置關(guān)系的操作。

在2D游戲中，同樣需要一套猶如SceneNode的場(chǎng)景管理節(jié)點(diǎn)，那么如何實(shí)現(xiàn)和設(shè)計(jì)一套用于2D的節(jié)點(diǎn)來調(diào)整空間關(guān)系呢？
  閱讀全文

     摘要: PyOgre安裝以及如何使用Blender導(dǎo)出Ogre的Mesh。  閱讀全文

     摘要: 蠻喜歡這句話的，當(dāng)生活中總是充滿了各種抱怨的時(shí)候，這句話總是讓人耳目一新。
當(dāng)我們抱怨的時(shí)候，為什么不動(dòng)手去改變它呢？有人說太遲了，what's done is done!
反過來思考這個(gè)問題，很多事情都已經(jīng)成了定局才讓我們抱怨和后悔，那之前做這些事的時(shí)候，或許就沒有用正確的方式來做才造成了現(xiàn)在的樣子。  閱讀全文

     摘要: vim, ctags, taglist 的一些基本使用方法的記錄～  閱讀全文

     摘要: 游戲主循環(huán)是每個(gè)游戲的心跳，輸送著整個(gè)游戲需要的養(yǎng)分。不幸的是沒有任何一篇好的文章來指導(dǎo)一個(gè)菜鳥游戲程序員如何為自己的程序供養(yǎng)。不過不用擔(dān)心，因?yàn)槟銊偤貌恍⌒目吹搅诉@篇，也是唯一一篇給予這個(gè)話題足夠重視的文章。

由于我身為游戲程序員，我見過許許多多的手機(jī)小游戲的代碼。這些代碼給我展示了五彩繽紛的游戲主循環(huán)實(shí)現(xiàn)方法。你可能要問：“這么簡(jiǎn)單的一個(gè)小玩意還能做到千奇百怪？” 事實(shí)就是這樣，我就會(huì)在此文中討論一些主流實(shí)現(xiàn)的優(yōu)缺點(diǎn)，并且給你介紹在我看來最好的輸送養(yǎng)分的解決方案。  閱讀全文

     摘要: 今天實(shí)訓(xùn)的某同學(xué)給我看了一段簡(jiǎn)單的代碼，蠻有意思~數(shù)組不是越界了么？為什么結(jié)果還是正確的呢？  閱讀全文

問題是這樣的，這個(gè)“項(xiàng)目”經(jīng)歷了種種變更，目前需求定格在3D動(dòng)作類游戲上。
在游戲引擎制作的過程中遇見了現(xiàn)在這樣的問題：

某從業(yè)人員即一位有經(jīng)驗(yàn)的XNA開發(fā)者告訴我們小型游戲利用XNA來做會(huì)比較有效率（相對(duì)后一種方案）。
不過現(xiàn)在問題出在對(duì).Net，XNA都不是十分熟悉，去使用XNA必然又比較大的學(xué)習(xí)代價(jià)。

后一種方案：使用OGRE+各種游戲引擎中還需要的其他類庫來做自己的游戲引擎
相對(duì)于.NET C# XNA，C++應(yīng)該在語言的熟悉程度上更好一些
OGRE也接觸了一些，不算熟悉，但是也能了解基本運(yùn)用
也就是后者可能在整合的方面會(huì)遇見一些更實(shí)際的問題，但是大體還熟悉

而前者XNA是一個(gè)不錯(cuò)的游戲開發(fā)框架，但是卻需要付出學(xué)習(xí)代價(jià)

后者的問題…… 其實(shí)我也只是聽同學(xué)提到一個(gè)很模糊的說法：“在后期會(huì)遇見一些麻煩”
這個(gè)說法也是前文中的那位從業(yè)人員給我同學(xué)的說法。
而實(shí)際上，我更傾向于的是后面這種解決方案~
因?yàn)閺淖约旱闹R(shí)層面和項(xiàng)目組成員的知識(shí)層面上來說，C++還是比C#要熟悉一些
OGRE對(duì)于一個(gè)基本完全未知的XNA藥熟悉一些。

希望有相關(guān)開發(fā)經(jīng)驗(yàn)的大大能夠來幫忙解決下心中的疑惑！到底是用XNA+.NET還是OGRE+C++
游戲規(guī)模是中小型，平臺(tái)現(xiàn)在由于各種原因限制在Windows上
這兩套解決方案到底孰優(yōu)孰劣？好又好在什么地方，缺點(diǎn)又有一些什么？
實(shí)際應(yīng)用上，會(huì)出現(xiàn)很棘手的麻煩么？

我自己也深知在這種解決方案上去徘徊遠(yuǎn)不如靜下心選定一個(gè)方案去解決現(xiàn)實(shí)世界的問題來得實(shí)際。
不過我自己心中有一個(gè)“潛選擇”，我怕前者真的是一套好的方案卻被放棄掉

希望各位大大支招，謝謝了~！

寫了幾天代碼，怕自己沒頭沒腦一直寫下去
還是乖乖的跑去圖書館看書

下面都是一些片段，都是自己覺得有意思的地方，所以還是記下來比較好

TC++PL 15.4.5
Object過于一般，因?yàn)樗⒉粚?duì)應(yīng)于應(yīng)用領(lǐng)域中的任何抽象，還迫使應(yīng)用程序員去使用一個(gè)實(shí)現(xiàn)層的抽象。解決這類問題的更好方式是使用容器模板，在其中只保存某一類指針……

TC++PL 15.5
然而，一個(gè)指向成員的指針并不像指向一個(gè)變量或者指向一個(gè)函數(shù)的指針，它并不是一個(gè)指向一塊內(nèi)存的指針。這種指針更像是一個(gè)結(jié)構(gòu)里的偏移量，或者到一個(gè)數(shù)組里的下標(biāo)。

這也很好的解釋了

typedef (Class::*mem_fun_ptr)(argus..);
的mem_fun_ptr要和一個(gè)class的實(shí)體結(jié)合使用…… 就像把這個(gè) 偏移量 施加在這個(gè) 結(jié)構(gòu)體 上

mem_fun_ptr mfptr = &Class::one_mem_fun;

Class *p = new Class;
Class instance;

(p->*mfptr)();

TC++PL 18.4.4.1
注釋中的 Curring化 正是OwnWaterloo學(xué)長(zhǎng)正在做的callback_curring ..

f(x,y) 看作 f(x)(y)

TC++PL 17.4.1末尾

std::map::inserat(val)返回std::pair<iterator,bool>
如果val被實(shí)際插入（可能由于已經(jīng)存在的key不能插入）那么bool為true。迭代器引用的是map中的一個(gè)元素，
它保存著val的關(guān)鍵嗎val.first。

TC++PL 17.4.2
關(guān)于multimap中查找某key得到的返回值

void print_numbers(const multimap<string,int>& phone_book)
{
    typedef multimap<string,int>::const_iterator I;
    pair<I,I> result = phone_book.equal_range("name");
    for (I i = result.first; i!=b.second; ++i) cout<<i->second<<endl;
}

關(guān)于tri的hash_map，boost是一個(gè)好東西
相對(duì)于utility pack來升級(jí)支持tr1使用boost反而有更好的移植性
#include <boost/tr1/unordered_map.hpp>

std::tr1::unordered_map<key_type,val_type> hashmap;

TC++PL 17章忠告中第10條
盡量使用最小的操作集合，以取得最大的靈活性

------------------------

標(biāo)準(zhǔn)庫容器中的元素必須可以復(fù)制
在使用 noncopyable 的時(shí)候應(yīng)該注意這一點(diǎn)