讓人無語的boost

    關(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í)：

    template <typename _Tp>
    void func( _Tp t );

    我總要花掉幾秒鐘時(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è)什么？考慮有：

    template <typename _Tp>
    void func( _Tp t );

    而我這個(gè)時(shí)候要傳遞一個(gè)類對(duì)象過去CBaseObject obj。為了效率，我寫下如下的代碼：

    template <typename _Tp>
    class ref_wrapper
    {
    public:
        ref_wrapper( _Tp &p ) : _obj( &p ) { }
        operator _Tp& () { return *_obj; }    
    private:
        _Tp *_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)用，如：

    template <typename _Tp>
    ref_wrapper<_Tp> ref( _Tp &t )
    {
        return ref_wrapper<_Tp>( t );
    }

    這樣調(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)：

    class base_type
    {
        virtual ~base_type() { }
    };
    template <typename _Tp>
    class var_wrapper
    {
    public:
        var_wrapper( const _Tp &t ) : _t( t )  {}
        operator _Tp& () { return _t; }
    private:
        _Tp _t;
    };   

    class var_list
    {
    public:
        typedef std::vector<base_type*> TypeList;
    public:
        
        template <typename _Tp>
        void add( const _Tp &t )
        {
            var_wrapper<_Tp> *var = new var_wrapper<_Tp>( t );
            _list.push_back( t );
        } 

        template <typename _Tp>
        _Tp &get( size_t index )
        {
            base_type *base = _list.at( index );
            typedef var_wrapper<_Tp> var_type;
            var_type *var = static_cast<var_type*>( base );
            return *var;
        }
    private:
        TypeList _list;
    }; 

    說白了，我就是利用一個(gè)包裝類將各種類型包裝其中，然后利用基類指針實(shí)現(xiàn)統(tǒng)一管理。直白地說，我
對(duì)這個(gè)組件不滿意。讓人詬病的是，get接口是類型不安全的。例如：

    int a; 
    CBaseObject obj;
    var_list my_var_list;
    my_var_list.add<int>( a );
    my_var_list.add<CBaseObject>( obj );

    取出值的時(shí)候：

    int b = my_var_list.get<int>( 0 );
    CBaseObject cobj = my_var_list.get<CBaseObject>( 1 );

    但是，因?yàn)間et沒有類型檢查，即使你：

    CBaseObject cobj = my_var_list.get<CBaseObject>( 0 );

    也不會(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 more
information...
    現(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++