• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            loop_in_codes

            低調做技術__歡迎移步我的獨立博客 codemaro.com 微博 kevinlynx

            讓人無語的boost

                關于BOOST,撞車,嚴重撞車。每一次都讓我有點無語。
                第一次是我所謂的宏遞歸,其實就是一個macro library,有一天就不小心在BOOST的library list上
            看到了這個東西。當然,BOOST很牛,別人的這個macro是真的library。但是,我們的需求撞車,我們的
            實現(xiàn)手段撞車。于是下定決心下次想要實現(xiàn)個什么東西的時候,先去看看BOOST,可以省掉不少腦力。
                本來就沒有做好,何必吃力不討好?
                第二次,當我寫下類似的模板代碼時:

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


                我總要花掉幾秒鐘時間去決策func的參數(shù)是用_Tp&還是_Tp,也就是所謂的究竟是按值傳送還是按引用
            傳送。如果按值傳送,當_Tp為一個類時,復制的東西過多時,顯然效率上過不去。作為func的實現(xiàn)者,良
            心上更過不去。后來一想,STL的各種算法里到處都是按值傳送,這樣做總有它的理由吧?
                但是,這樣做就是不夠完美。
                于是想起了boost::ref。但是這個時候我并不知道boost::ref是個什么東西。我只是以前在各種地方
            看到過這個東西。我還是決定自己實現(xiàn)一個。
                實現(xiàn)一個什么?考慮有:

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


                而我這個時候要傳遞一個類對象過去CBaseObject obj。為了效率,我寫下如下的代碼:

                template <typename _Tp>
                
            class ref_wrapper
                
            {
                
            public:
                    ref_wrapper( _Tp 
            &p ) : _obj( &p ) { }
                    
            operator _Tp& () return *_obj; }    
                
            private:
                    _Tp 
            *_obj;
                }
            ;


                然后再使用func時,func( ref_wrapper<CBaseObject>( obj ) );這樣,發(fā)生復制操作的最多就是這
            個ref_wrapper,基本上也就是復制了一個指針,而不會復制整個obj。當然,這里可以寫一個模板函數(shù)去
            簡化func的調用,如:

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


                這樣調用的時候就簡單了:func( ref( obj ) );
                其實這就是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的字眼。

                好,接下來說說第三次。
                第三次我遇到了這樣一種需求,我需要一個容器,就像你知道的std::list。但是與std::list甚至STL
            中所有容器都不同的是,這個容器里保存的東西具有不同的類型。
                這個時候我想起了tuple。我沒有實現(xiàn)過tuple。大致上這個東西的實現(xiàn)原理就是利用類型遞歸來保存
            數(shù)據(jù),就像loki的type list。另一方面,tuple的尺寸似乎不能動態(tài)增長。
                于是我有了自己撇腳的實現(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;
                }

             

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

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


                取出值的時候:

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


                但是,因為get沒有類型檢查,即使你:

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


                也不會出錯,編譯器不會給予你警告。
                事情到此結束,這個類型不安全的組件只能依靠程序員自己的謹慎去生存。

                然后,又是一個不小心,我在boost里看到了any。boost::any庫同boost::ref庫一樣,是一個tiny
            library。幾十行的代碼一目了然。
                boost::any有一個placeholder基類,有一個template <typename ValueType> holder派生類,然后有
            一個提供給外部的any類。看了代碼后有一種讓我噴血的感覺。其實現(xiàn)原理和我自己的完全一致。
                比較而言,我覺得我的var_list撇腳到了極致。因為我封裝了容器,而這顯然是沒必要的,并且限制
            了其使用范圍。而boost::any則是僅僅封裝了類型。
                數(shù)據(jù)轉換方面,boost::any提供了any_cast和unsafe_any_cast。unsafe_any_cast和我這里用的轉換
            差不多,也就是我說的類型不安全。而他的any_cast呢?則是用到了typeid,多了次類型檢查而已。
                沒辦法,看來var_list需要被刪掉,直接搬boost::any過來吧,同樣地check out boost::any for more
            information...
                現(xiàn)在看來,boost真的很強大。我感覺再怎么偏門的需求,都能在boost里找到個實現(xiàn)。痛定思痛,決定
            把boost doc長期開著。

            posted on 2008-10-15 11:23 Kevin Lynx 閱讀(4749) 評論(10)  編輯 收藏 引用 所屬分類: c/c++

            評論

            # re: 讓人無語的boost 2008-10-15 12:04 Fox

            你停太久了……  回復  更多評論   

            # re: 讓人無語的boost[未登錄] 2008-10-15 12:17 chinablueker

            沒有十全十美的實現(xiàn)、架構亦如此。

            抓住關鍵需求。  回復  更多評論   

            # re: 讓人無語的boost 2008-10-15 12:42 金慶

            用到了才知道boost好。我也在學著應用boost.  回復  更多評論   

            # re: 讓人無語的boost 2008-10-15 14:06 LOGOS

            我是看到boost就貼邊走
            咱惹不起,還躲得起  回復  更多評論   

            # re: 讓人無語的boost[未登錄] 2008-10-15 18:58 missdeer

            我也是,過了之后才發(fā)現(xiàn),boost里有更好的……  回復  更多評論   

            # re: 讓人無語的boost 2008-10-15 21:16 littlewater

            偶記得ANY似乎需要RTTI支持……
            遞歸宏很贊,一直使用著……老實說BOOST的那個偶不用的……  回復  更多評論   

            # re: 讓人無語的boost[未登錄] 2008-10-15 23:45 Kevin Lynx

            @littlewater
            boost::any用到了typeid,這個東西不開RTTI還是可以工作的,但是對于具有vtable的類,要讓typeid工作,就需要開RTTI。
              回復  更多評論   

            # re: 讓人無語的boost[未登錄] 2008-10-17 09:49 bugs

            博大精深。  回復  更多評論   

            # re: 讓人無語的boost 2008-12-27 09:27 littlewater

            啊這樣子的啊?
            謝謝指點^^不過不開RTTI為什么typeid還可以工作呢??

            機器掛了,以前的鏈接都沒了,好不容易回來^^
              回復  更多評論   

            # re: 讓人無語的boost[未登錄] 2008-12-28 18:16 Kevin Lynx

            :)
            不開RTTI,typeid只對靜態(tài)類型有效了,也就是只對編譯器就可以確定的類型有效。
              回復  更多評論   

            亚洲AV无码久久精品蜜桃| 久久精品人成免费| 亚洲国产二区三区久久| 成人a毛片久久免费播放| 久久久久99精品成人片| 99久久综合国产精品免费| 无码人妻久久一区二区三区免费 | 秋霞久久国产精品电影院| 99久久无码一区人妻| 日本三级久久网| 99久久亚洲综合精品网站| 国产真实乱对白精彩久久| 久久久久国产精品人妻| 中文字幕成人精品久久不卡| 亚洲午夜久久影院| 久久91精品国产91久久小草| 久久国产成人午夜AV影院| 久久综合九色欧美综合狠狠| 国产精品久久网| 亚洲国产精品一区二区久久hs| 久久人人爽人人爽人人片AV麻烦| 日产精品久久久一区二区| 亚洲人成网站999久久久综合| 国产成人无码久久久精品一| 久久免费视频1| 久久综合精品国产一区二区三区 | 国内精品久久久久影院优| 99久久精品国内| 亚洲欧美日韩精品久久亚洲区| 久久国产劲爆AV内射—百度| 免费精品99久久国产综合精品| 久久亚洲国产成人精品无码区| 久久国产欧美日韩精品| 国产高潮国产高潮久久久91| 手机看片久久高清国产日韩| 欧美一区二区精品久久| 亚洲欧美一级久久精品| 日本久久久久久中文字幕| 久久久久亚洲AV无码专区体验| 久久精品无码一区二区app| 久久99精品久久只有精品|