到了真的動手干，才知道自己的基礎(chǔ)這么弱，幾乎能夠不斷的遇到C++和openGL上的問題，這樣工作起來既有挫折感也蠻有成就感的。
寫Node類的時候遇到一個map和hash_map的問題，在Ogre的實現(xiàn)中對于SceneNode的children使用的hash_map，而不是map，引起了我的興趣，后來在STL China上找到一篇介紹兩者區(qū)別的文章。簡單的總結(jié)一下，就是說hash_map同map比較起來，利用了哈希表進行存儲，而不是map的RB tree，這樣占用多一點空間，節(jié)省一些查找時間。因為hash_map基本是常量的查找速度，而map是log(n)的查找速度，因此實際上對于小數(shù)據(jù)量的情況，大可不必使用hash_map.綜上，權(quán)衡三個因素: 查找速度, 數(shù)據(jù)量, 內(nèi)存使用。
- 2006年3月2日 inline函數(shù)和const問題
以前就注意過dvesg中實現(xiàn)getter的時候通常有兩個函數(shù)，分別類似于下面的情況：
inline const ParentList& getParents() const { return _parents; }
inline ParentList getParents() { return _parents; }
首先是inline，google了一下找到三篇文章：保守的使用inline，新手入門：關(guān)于C++中的內(nèi)聯(lián)函數(shù)(inline)和C++箴言：理解inline化的介入和排除。總結(jié)一下，inline函數(shù)主要是通過在編譯階段將調(diào)用inline函數(shù)的地方替換成內(nèi)聯(lián)函數(shù)本身，從而在程序執(zhí)行階段減少調(diào)用的次數(shù)，也就減少了系統(tǒng)中棧空間的頻繁操作，因此算是一種用空間換時間的優(yōu)化手段。但是使用的時候也需要多加注意。首先是inline函數(shù)中不能有while，switch，不能遞歸調(diào)用，防止?jié)撛诘拇a膨脹，另外要注意inline函數(shù)編譯出來的程序也根據(jù)編譯器的不同而有所不同。還有一點不太理解的：不要僅僅因為函數(shù)模板出現(xiàn)在頭文件中，就將它聲明為 inline。
然后再重提一下const問題。在google隨便一搜很容易找到一篇const用法的文章，毛病一大堆，但是看到了很多以前沒有遇到過的情況。看了以后覺得沒有記住多少，還是要在實際應(yīng)用中碰到的會印象深刻。反正const用的好，程序很健壯，用不好麻煩一大堆，要逐漸積累經(jīng)驗。現(xiàn)在我所知道的const：
1，const在*前表示指針的內(nèi)容是常量，*在const前表示指針地址是常量，不能指向其他地址。
2，const在成員函數(shù)前，表示返回值是常量；const在成員函數(shù)后表示該函數(shù)不能修改函數(shù)成員。
對于上邊那段代碼的理解也找到了：“常函數(shù)的調(diào)用是這樣的：常量對象只能調(diào)用常成員函數(shù)，非常量對象即可以調(diào)常成員函數(shù)，也可以調(diào)一般成員函數(shù)，但當(dāng)某個函數(shù)有const和非const兩個版本時，const對象調(diào)const版本，非const對象調(diào)非const版本”。
- 2006年3月7日 map使用中的問題以及inline函數(shù)的編譯問題，詭異的程序異常
為了按名操作Geometry對象，聲明了typedef map<string,refptr<Geometry> > GeometryList;在使用的時候，要插入一個數(shù)據(jù)，使用geoList[a]=b;我發(fā)現(xiàn)在一個方法里邊這樣做了以后，又調(diào)用了refptr的析構(gòu)函數(shù)，這樣如果智能指針計數(shù)為0，那指針豈不被析構(gòu)了。偏巧程序這時候運行退出時報異常，搞的我以為是這里出了問題。后來才發(fā)現(xiàn)在這個過程中，首先執(zhí)行refptr的拷貝構(gòu)造函數(shù)，構(gòu)造一個對象，然后把string和智能指針放在map自己的數(shù)據(jù)中。不存在上述問題。
還有我做了refptr<T>的＝號操作符重載，因此每次我在插入一個Geometry的時候，實際只要執(zhí)行：Geometry* geo；mymap[name]=geo;就可以了，不必使用mymap[name]=refptr<Geometry>(geo);還是參考了前人寫的程序才發(fā)現(xiàn)可以這么簡單。其實c++可以很簡單，只是我們不能掌握它的規(guī)則。唉，還得學(xué)啊！
zjn今天終于調(diào)通了3ds的loader。原因是前邊他把loader中全局的方法，在聲明處就進行了實現(xiàn)，據(jù)他說c＋＋會默認(rèn)這種情況為inline函數(shù)，這樣導(dǎo)致在設(shè)定的lib目錄中看不到編譯好的lib文件。因為inline的函數(shù)是不能在前邊放EXPORT_DLL的編譯鏈接輸出到DLL的，要在client程序include時進行編譯，這樣才會節(jié)省棧調(diào)用。后來把這些函數(shù)放在一個類里邊實現(xiàn)就調(diào)通了。
今天還碰到另外一個異常的問題。“Unhandled Exception:User breakpoint”,在我和zjn那里都碰到了這個異常。后來我發(fā)現(xiàn)時yyd的程序里邊把color的V4Array的size設(shè)為3，而設(shè)定的時候?qū)懥?*color)[3]=V4(0,1,0,1);這樣導(dǎo)致析構(gòu)的時候異常。但是zjn那里的異常就跟我這個不同，他那里把string作為map的key，在設(shè)定Geometry的時候到第八個Geometry就會跳出上述異常，從函數(shù)調(diào)用來看是string的析構(gòu)函數(shù)有問題，后來換了不從3ds中讀這個string，而自己設(shè)定序號，就沒有異常。唉，c++程序這個東西真是詭異。