• <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>

            關(guān)于hash_map的一點(diǎn)感悟

               工作兩年中,關(guān)于查找敏感型的代碼不少用到了hash_map,關(guān)于它的實現(xiàn)細(xì)節(jié)和需要注意的地方這里梳理一下。因為工作在linux環(huán)境下,所以這里hash_map的評述都是根據(jù)SGI的源碼。 
               hash_map說簡單一點(diǎn)就是一個hashtable桶和對于這個桶基本操作的再次封裝。即包含(圖片太麻煩,文字代替吧):1、_Hashtable* _M_ht;2、erase()、find()等函數(shù)。對應(yīng)的iterator包含:1、_hashtable* _M_ht(這個就是hash_map中的hashtable指針);2、_Node* _M_cur(指向當(dāng)前hashtable桶的某個節(jié)點(diǎn))。_Node的結(jié)構(gòu)為: 
              template <class _Val>
                struct _Hashtable_node
                {
                  _Hashtable_node* _M_next;
                  _Val _M_val; //桶的節(jié)點(diǎn),具體是實現(xiàn)使用的Vector,后面有介紹
                };
               所以hash_map的實現(xiàn)主要是hashtable的實現(xiàn)。下面看一下hashtable的組成(private成員):
                  hasher                _M_hash; //hasher,處理沖突時用到的,是hashtable性能如何的關(guān)鍵因素之一
                  key_equal             _M_equals;//鍵值是否相等的函數(shù),std::string等非基本數(shù)據(jù)類型做鍵值時需要提供此函數(shù)
                  _ExtractKey           _M_get_key;//和Alloc相關(guān)的函數(shù)
                  _Vector_type          _M_buckets;//hashtable桶的基本元素,SGI實現(xiàn)是 vector<_Node*, _Nodeptr_Alloc>
                  size_type             _M_num_elements;//標(biāo)示hashtable元素個數(shù),size()函數(shù)返回的即是此值
               撇去具體實現(xiàn)細(xì)節(jié),hashtable基本上也就這些內(nèi)容(基本也就是一個很大的vector,每個vector節(jié)點(diǎn)掛著一個形同list存放沖突節(jié)點(diǎn))。
               插入(方法有insert和operator[])過程:
            1. 調(diào)用resize()     判斷是否調(diào)整桶的大小,桶的不同大小SGI實現(xiàn)是很有講究的,具體參見__stl_prime_list 數(shù)組
            2. 得到key   通過_M_bkt_num(__obj)
            3. 通過hash函數(shù)得到hash值   通過_M_hash(__key)
            4. 得到桶號(一般都為hash值對桶數(shù)求模)    通過_M_hash(__key) % __n
            5. 存放key和value在桶內(nèi)。


               取值(find后通過iterator或者operator[])過程:
            1. 得到key       _M_bkt_num_key(__key)
            2. 通過hash函數(shù)得到hash值   通過_M_hash(__key)
            3. 得到桶號(一般都為hash值對桶數(shù)求模)   通過_M_hash(__key) % __n
            4. 比較桶的鏈表上元素是否與key相等,若都不相等,則沒有找到。
            5. 取出相等的記錄的value。  find()方法返回 iterator(__first, this)
            下面再說說iterator的操作,因為它是比較容易出錯的。
            begin()操作是用一個for循環(huán),在hashtable上面的vector里找到第一個即_M_buckets[__n]指針不為空的 iterator(_M_buckets[__n], this)
            end()操作返回 iterator(0, this)
            operator++ 操作是從_M_cur開始,優(yōu)先_M_cur->_M_next,為空時遍歷vector直至找到一個_M_cur不為空的節(jié)點(diǎn)
            迭代器操作使用不當(dāng),很容易出問題,hash_map的也不例外,具體看后面代碼例子。
            注意到hash_map默認(rèn)的構(gòu)造函數(shù)       hash_map()
                  : _M_ht(100, hasher(), key_equal(), allocator_type()) {}
               默認(rèn)是初始化一個100個hashtable桶元素,如果你的hash_map用不到這么多元素,建議不要使用默認(rèn)值。
            hash_map的鍵值一經(jīng)插入,使用期間不要更改(有時候時內(nèi)存釋放等造成的),否則會釀造悲劇,如下例:
             
            /**
             *\author peakflys
             *\brief 演示hash_map鍵值更改造成的問題
             
            */
            #include <iostream>
            #include <ext/hash_map>
            struct Unit
            {
                char name[32];
                unsigned int score;
                Unit(const char *_name,const unsigned int _score) : score(_score)
                {   
                    strncpy(name,_name,32);
                }   
            };
            int main()
            {
                typedef __gnu_cxx::hash_map<char*,Unit*> uHMap;
                typedef uHMap::value_type hmType;
                typedef uHMap::iterator hmIter;
                uHMap hMap;
                Unit *unit1 = new Unit("peak",100);
                Unit *unit2 = new Unit("Joey",20);
                Unit *unit3 = new Unit("Rachel",40);
                Unit *unit4 = new Unit("Monica",90);
                hMap[unit1->name] = unit1;
                hMap[unit2->name] = unit2;
                hMap.insert(hmType(unit3->name,unit3));
                hMap.insert(hmType(unit4->name,unit4));
                for(hmIter it=hMap.begin();it!=hMap.end();++it)
                {   
                    std::cout<<it->first<<"\t"<<it->second->score<<std::endl;//正常操作
                }   
                for(hmIter it=hMap.begin();it!=hMap.end();++it)
               {
                    Unit *unit = it->second;
                    //hMap.erase(it++);
                    delete unit; //delete釋放節(jié)點(diǎn)內(nèi)存,但是hMap沒有除去,造成hMap內(nèi)部錯亂,有可能宕機(jī)
                } 
                 hmIter it = hMap.begin();
                strncpy(it->first,"cc",32);//強(qiáng)行更改
                for(hmIter it=hMap.begin();it!=hMap.end();++it)
                {   
                    std::cout<<it->first<<"\t"<<it->second->score<<std::endl;//死循環(huán),原因參加上面++操作說明
                }   
                return 0;
            }
            上面錯誤都是實際使用時很容易遇到的情況。暫時先寫到這里,VS下的hash_map的實現(xiàn)和SGI的相差比較大,例如hashtable動態(tài)大小的調(diào)整是完全按照vector2倍的策略增長等等。
               原創(chuàng)內(nèi)容,轉(zhuǎn)載注明作者和出處,謝謝。

            posted on 2012-07-24 14:15 peakflys 閱讀(7335) 評論(5)  編輯 收藏 引用 所屬分類: 數(shù)據(jù)結(jié)構(gòu)

            評論

            # re: 關(guān)于hash_map的一點(diǎn)感悟 2012-07-24 15:12 likun

            hmIter it = hMap.begin();
            strncpy(it->first,"cc",32);//強(qiáng)行更改
            for(hmIter it=hMap.begin();it!=hMap.end();++it)
            {
            std::cout<<it->first<<"\t"<<it->second->score<<std::endl;//死循環(huán),原因參加上面++操作說明
            }

            這里會出現(xiàn)死循環(huán)的原因能否說明白一點(diǎn)?不是很理解 啊。
            只是簡單的修改begin()單元里面的內(nèi)容,怎么會出現(xiàn)這樣的現(xiàn)象?  回復(fù)  更多評論   

            # re: 關(guān)于hash_map的一點(diǎn)感悟 2012-07-24 18:29 peakflys

            @likun原因很簡單,上面我也說過,operator++ 操作是從_M_cur開始,優(yōu)先_M_cur->_M_next,為空時遍歷vector直至找到一個_M_cur不為空的節(jié)點(diǎn),遍歷vector時需要取它對應(yīng)的桶位置(參砍上面hash_map取值過程),_M_bkt_num_key(key)中key的值是修改后的值,假如你改的鍵值,通過此函數(shù)得到的桶位置在你當(dāng)前元素之前,這樣就造成了死循環(huán)。  回復(fù)  更多評論   

            # re: 關(guān)于hash_map的一點(diǎn)感悟[未登錄] 2012-07-25 12:23 Chipset

            有時間試試gcc的unordered_map吧,注意版本號4.6.3以后的,4.6.2版本的哈希表比4.6.3的哈希表處理字符竄時慢的不是一點(diǎn)半點(diǎn)。處理大量字符竄,尤其字符竄很長時,因該比SGI_STL的哈希表快得多。gcc的哈希表處理整數(shù)可能比SGI_STL的哈希表要慢,主要是Allocator作怪。  回復(fù)  更多評論   

            # re: 關(guān)于hash_map的一點(diǎn)感悟 2012-08-05 22:39 egmkang

            @likun
            我跪了.這代碼你也寫的出啊.  回復(fù)  更多評論   

            # re: 關(guān)于hash_map的一點(diǎn)感悟 2013-05-14 17:38 peakflys

            呵呵,這種代碼大點(diǎn)的系統(tǒng),很多都是存在的,而潛在的錯誤可能還沒爆發(fā)出來@egmkang
              回復(fù)  更多評論   


            只有注冊用戶登錄后才能發(fā)表評論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            <2025年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            導(dǎo)航

            統(tǒng)計

            公告

            人不淡定的時候,就愛表現(xiàn)出來,敲代碼如此,偶爾的靈感亦如此……

            常用鏈接

            留言簿(4)

            隨筆分類

            隨筆檔案

            文章檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            粉嫩小泬无遮挡久久久久久| 欧美一级久久久久久久大| 四虎影视久久久免费| 国产精品xxxx国产喷水亚洲国产精品无码久久一区 | 国产精品久久久久一区二区三区| 久久久女人与动物群交毛片| 无码人妻久久一区二区三区免费丨| 久久久久久无码Av成人影院| 色偷偷888欧美精品久久久| 91精品免费久久久久久久久| 性高朝久久久久久久久久| 亚洲成色WWW久久网站| 国产三级观看久久| 亚洲精品无码专区久久久| 国产综合免费精品久久久| 久久99国产综合精品| 香蕉99久久国产综合精品宅男自 | 国内精品久久久久久中文字幕| 亚洲精品无码久久不卡| 亚洲中文精品久久久久久不卡| 国产激情久久久久影院小草| 亚洲综合日韩久久成人AV| 久久久久九九精品影院| 国内精品久久人妻互换| 久久国产AVJUST麻豆| 国产成人香蕉久久久久| 久久亚洲美女精品国产精品| 伊人色综合九久久天天蜜桃| 久久精品国产欧美日韩| 久久国产精品一区二区| 人妻丰满AV无码久久不卡| 久久亚洲AV永久无码精品| 国产精品免费久久久久电影网| 久久久久成人精品无码中文字幕| 无码乱码观看精品久久| 久久亚洲国产精品五月天婷| 精品久久人人爽天天玩人人妻 | 99久久国产综合精品网成人影院 | 少妇人妻综合久久中文字幕| 日日狠狠久久偷偷色综合0| 欧美激情精品久久久久久久 |