低調(diào)做技術(shù)__歡迎移步我的獨(dú)立博客 codemaro.com 微博 kevinlynx
關(guān)于BOOST,撞車,嚴(yán)重撞車。每一次都讓我有點(diǎn)無語。 第一次是我所謂的宏遞歸,其實(shí)就是一個(gè)macro library,有一天就不小心在BOOST的library list上看到了這個(gè)東西。當(dāng)然,BOOST很牛,別人的這個(gè)macro是真的library。但是,我們的需求撞車,我們的實(shí)現(xiàn)手段撞車。于是下定決心下次想要實(shí)現(xiàn)個(gè)什么東西的時(shí)候,先去看看BOOST,可以省掉不少腦力。 本來就沒有做好,何必吃力不討好? 第二次,當(dāng)我寫下類似的模板代碼時(shí):
我總要花掉幾秒鐘時(shí)間去決策func的參數(shù)是用_Tp&還是_Tp,也就是所謂的究竟是按值傳送還是按引用傳送。如果按值傳送,當(dāng)_Tp為一個(gè)類時(shí),復(fù)制的東西過多時(shí),顯然效率上過不去。作為func的實(shí)現(xiàn)者,良心上更過不去。后來一想,STL的各種算法里到處都是按值傳送,這樣做總有它的理由吧? 但是,這樣做就是不夠完美。 于是想起了boost::ref。但是這個(gè)時(shí)候我并不知道boost::ref是個(gè)什么東西。我只是以前在各種地方看到過這個(gè)東西。我還是決定自己實(shí)現(xiàn)一個(gè)。 實(shí)現(xiàn)一個(gè)什么?考慮有:
而我這個(gè)時(shí)候要傳遞一個(gè)類對(duì)象過去CBaseObject obj。為了效率,我寫下如下的代碼:
然后再使用func時(shí),func( ref_wrapper<CBaseObject>( obj ) );這樣,發(fā)生復(fù)制操作的最多就是這個(gè)ref_wrapper,基本上也就是復(fù)制了一個(gè)指針,而不會(huì)復(fù)制整個(gè)obj。當(dāng)然,這里可以寫一個(gè)模板函數(shù)去簡(jiǎn)化func的調(diào)用,如:
這樣調(diào)用的時(shí)候就簡(jiǎn)單了:func( ref( obj ) ); 其實(shí)這就是boost的ref庫,按照其官方文檔,ref庫就是: The Ref library is a small library that is useful for passing references to function templates (algorithms) that would usually take copies of their arguments.
然后我就懵了。于是我不得不在kl_ref.h里寫上check out boost::ref for more information的字眼。
好,接下來說說第三次。 第三次我遇到了這樣一種需求,我需要一個(gè)容器,就像你知道的std::list。但是與std::list甚至STL中所有容器都不同的是,這個(gè)容器里保存的東西具有不同的類型。 這個(gè)時(shí)候我想起了tuple。我沒有實(shí)現(xiàn)過tuple。大致上這個(gè)東西的實(shí)現(xiàn)原理就是利用類型遞歸來保存數(shù)據(jù),就像loki的type list。另一方面,tuple的尺寸似乎不能動(dòng)態(tài)增長(zhǎng)。 于是我有了自己撇腳的實(shí)現(xiàn):
說白了,我就是利用一個(gè)包裝類將各種類型包裝其中,然后利用基類指針實(shí)現(xiàn)統(tǒng)一管理。直白地說,我對(duì)這個(gè)組件不滿意。讓人詬病的是,get接口是類型不安全的。例如:
取出值的時(shí)候:
但是,因?yàn)間et沒有類型檢查,即使你:
也不會(huì)出錯(cuò),編譯器不會(huì)給予你警告。 事情到此結(jié)束,這個(gè)類型不安全的組件只能依靠程序員自己的謹(jǐn)慎去生存。
然后,又是一個(gè)不小心,我在boost里看到了any。boost::any庫同boost::ref庫一樣,是一個(gè)tiny library。幾十行的代碼一目了然。 boost::any有一個(gè)placeholder基類,有一個(gè)template <typename ValueType> holder派生類,然后有一個(gè)提供給外部的any類。看了代碼后有一種讓我噴血的感覺。其實(shí)現(xiàn)原理和我自己的完全一致。 比較而言,我覺得我的var_list撇腳到了極致。因?yàn)槲曳庋b了容器,而這顯然是沒必要的,并且限制了其使用范圍。而boost::any則是僅僅封裝了類型。 數(shù)據(jù)轉(zhuǎn)換方面,boost::any提供了any_cast和unsafe_any_cast。unsafe_any_cast和我這里用的轉(zhuǎn)換差不多,也就是我說的類型不安全。而他的any_cast呢?則是用到了typeid,多了次類型檢查而已。 沒辦法,看來var_list需要被刪掉,直接搬boost::any過來吧,同樣地check out boost::any for moreinformation... 現(xiàn)在看來,boost真的很強(qiáng)大。我感覺再怎么偏門的需求,都能在boost里找到個(gè)實(shí)現(xiàn)。痛定思痛,決定把boost doc長(zhǎng)期開著。
posted on 2008-10-15 11:23 Kevin Lynx 閱讀(4774) 評(píng)論(10) 編輯 收藏 引用 所屬分類: c/c++
你停太久了…… 回復(fù) 更多評(píng)論
沒有十全十美的實(shí)現(xiàn)、架構(gòu)亦如此。抓住關(guān)鍵需求。 回復(fù) 更多評(píng)論
用到了才知道boost好。我也在學(xué)著應(yīng)用boost. 回復(fù) 更多評(píng)論
我是看到boost就貼邊走 咱惹不起,還躲得起 回復(fù) 更多評(píng)論
我也是,過了之后才發(fā)現(xiàn),boost里有更好的…… 回復(fù) 更多評(píng)論
偶記得ANY似乎需要RTTI支持…… 遞歸宏很贊,一直使用著……老實(shí)說BOOST的那個(gè)偶不用的…… 回復(fù) 更多評(píng)論
@littlewater boost::any用到了typeid,這個(gè)東西不開RTTI還是可以工作的,但是對(duì)于具有vtable的類,要讓typeid工作,就需要開RTTI。 回復(fù) 更多評(píng)論
博大精深。 回復(fù) 更多評(píng)論
啊這樣子的啊? 謝謝指點(diǎn)^^不過不開RTTI為什么typeid還可以工作呢?? 機(jī)器掛了,以前的鏈接都沒了,好不容易回來^^ 回復(fù) 更多評(píng)論
:) 不開RTTI,typeid只對(duì)靜態(tài)類型有效了,也就是只對(duì)編譯器就可以確定的類型有效。 回復(fù) 更多評(píng)論
Powered by: C++博客 Copyright © Kevin Lynx