青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

xiaoguozi's Blog
Pay it forword - 我并不覺的自豪,我所嘗試的事情都失敗了······習慣原本生活的人不容易改變,就算現(xiàn)狀很糟,他們也很難改變,在過程中,他們還是放棄了······他們一放棄,大家就都是輸家······讓愛傳出去,很困難,也無法預料,人們需要更細心的觀察別人,要隨時注意才能保護別人,因為他們未必知道自己要什么·····

說來慚愧,使用了很久Visual Stdio 2003了,只知道MFC升級到了7.0,ATL也升級到了7.0,對于這兩個經(jīng)典的類庫做了一些研究,但一直沒有注意C++標準庫的變化。

     今天嘗試的使用了stdext::hash_map這個庫,果然不錯。下面寫下一些心得。

     hash_map類在頭文件hash_map中,和所有其它的C++標準庫一樣,頭文件沒有擴展名。如下聲明:

          #include <hash_map>
          using namespace std;
          using namespace stdext;

     hash_map是一個聚合類,它繼承自_Hash類,包括一個vector,一個list和一個pair,其中vector用于保存桶,list用于進行沖突處理,pair用于保存key->value結(jié)構(gòu),簡要地偽碼如下:

          class hash_map<class _Tkey, class _Tval>
          {
          private:
               typedef pair<_Tkey, _Tval> hash_pair;
               typedef list<hash_pair>    hash_list;
               typedef vector<hash_list>  hash_table;
          };

     當然,這只是一個簡單模型,C++標準庫的泛型模版一向以嵌套復雜而聞名,初學時看類庫,無疑天書啊。微軟的hash_map類還聚合了hash_compare仿函數(shù)類,hash_compare類里有聚合了less仿函數(shù)類,亂七八糟的。

     下面說說使用方法:

     一、簡單變量作為索引:整形、實性、指針型
     其實指針型也就是整形,算法一樣。但是hash_map會對char*, const char*, wchar_t*, const wchar_t*做特殊處理。
     這種情況最簡單,下面代碼是整形示例:
            hash_map<int, int> IntHash;
            IntHash[1] = 123;
            IntHash[2] = 456;

            int val = IntHash[1];
            int val = IntHash[2];
     實型和指針型用法和整形一樣,原理如下:
     1、使用簡單類型作索引聲明hash_map的時候,不需要聲明模版的后兩個參數(shù)(最后一個參數(shù)指名hash_map節(jié)點的存儲方式,默認為pair,我覺得這就挺好,沒必要修改),使用默認值就好。
     2、對于除過字符串的其它簡單類型,hash_map使用模版函數(shù) size_t hash_value(const _Kty& _Keyval) 計算hash值,計算方法是經(jīng)典的掩碼異或法,自動溢出得到索引hash值。微軟的工程師也許開了一個玩笑,這個掩碼被定義為0xdeadbeef(死牛肉,抑或是某個程序員的外號)。
     3、對于字符串指針作索引的時候,使用定類型函數(shù)inline size_t hash_value(const char *_Str)或inline size_t hash_value(const wchar_t *_Str)計算hash值,計算方法是取出每一個字符求和,自動溢出得到hash值。對于字符串型的hash索引,要注意需要自定義less仿函數(shù)。
     因為我們有理由認為,人們使用hash表進行快速查找的預期成本要比在hash表中插入的預期成本低得多,所以插入可以比查找昂貴些;基于這個假設,hash_map在有沖突時,插入鏈表是進行排序插入的,這樣在進行查詢沖突解決的時候就能夠更快捷的找到需要的索引。
     但是,基于泛型編程的原則,hash_map也有理由認為每一種類型都支持使用"<"來判別兩個類型值的大小,這種設計恰好讓字符串類型無所適從,眾所周知,兩個字符串指針的大小并不代表字符串值的大小。見如下代碼:
          hash_map<const char*, int> CharHash;
          CharHash["a"] = 123;
          CharHash["b"] = 456;

          char szInput[64] = "";
          scanf("%s", szInput);

          int val = CharHash[szInput];

     最終的結(jié)果就是無論輸入任何字符串,都無法找到對應的整數(shù)值。因為輸入的字符串指針是szInput指針,和"a"或"b"字符串常量指針的大小是絕對不會相同。解決方法如下:
     首先寫一個仿函數(shù)CharLess,繼承自仿函數(shù)基類binary_function(當然也可以不繼承,這樣寫只是符合標準,而且寫起來比較方便,不用被類似于指針的指針和指針的引用搞暈。

          struct CharLess : public binary_function<const char*, const char*, bool>
          {
          public:
               result_type operator()(const first_argument_type& _Left, const second_argument_type& _Right) const
               {
                    return(stricmp(_Left, _Right) < 0 ? true : false);
               }
          };

     很好,有了這個仿函數(shù),就可以正確的使用字符串指針型hash_map了。如下:

          hash_map<const char*, int, hash_compare<const char*, CharLess> > CharHash;
          CharHash["a"] = 123;
          CharHash["b"] = 456;

          char szInput[64] = "";
          scanf("%s", szInput);

          int val = CharHash[szInput];
     
     現(xiàn)在就可以正常工作了。至此,簡單類型的使用方法介紹完畢。

     二、用戶自定義類型:比如對象類型,結(jié)構(gòu)體。
     這種情況比價復雜,我們先說簡單的,對于C++標準庫的string類。
     
     慶幸的是,微軟為basic_string(string類的基類)提供了hash方法,這使得使用string對象做索引簡單了許多。值得注意(也值得郁悶)的是,雖然支持string的hash,string類卻沒有重載比較運算符,所以標準的hash_compare仿函數(shù)依舊無法工作。我們繼續(xù)重寫less仿函數(shù)。
         
          struct string_less : public binary_function<const string, const string, bool>
          {
          public:
               result_type operator()(const first_argument_type& _Left, const second_argument_type& _Right) const
               {
                    return(_Left.compare(_Right) < 0 ? true : fase);
               }
          };
           
     好了,我們可以書寫如下代碼:
           
          hash_map<string, int, hash_compare<string, string_less> > StringHash;
          StringHash["a"] = 123;
          StringHash["b"] = 456;

          string strKey = "a";

          int val = CharHash[strKey];
     
     這樣就可以了。
     
     對于另外的一個常用的字符串類CString(我認為微軟的CString比標準庫的string設計要灑脫一些)更加復雜一些。很顯然,標準庫里不包含對于CString的支持,但CString卻重載了比較運算符(郁悶)。我們必須重寫hash_compare仿函數(shù)。值得一提的是,在Virtual Stdio 2003中,CString不再是MFC的成員,而成為ATL的成員,使用#include <atlstr.h>就可以使用。我沒有采用重寫hash_compare仿函數(shù)的策略,而僅僅是繼承了它,在模版庫中的繼承是沒有性能損耗的,而且能讓我偷一點懶。
     首先重寫一個hash_value函數(shù):
     
          inline size_t CString_hash_value(const CString& str)
          {
               size_t value = _HASH_SEED;
               size_t size  = str.GetLength();
               if (size > 0) {
                    size_t temp = (size / 16) + 1;
                    size -= temp;
                    for (size_t idx = 0; idx <= size; idx += temp) {
                         value += (size_t)str[(int)idx];
                    }
               }
               return(value);
          }
     
     其次重寫hash_compare仿函數(shù):
     
          class CString_hash_compare : public hash_compare<CString>
          {
          public:
               size_t operator()(const CString& _Key) const
               {
                    return((size_t)CString_hash_value(_Key));
               }
  
               bool operator()(const CString& _Keyval1, const CString& _Keyval2) const
               {
                    return (comp(_Keyval1, _Keyval2));
               }
          };
           
     上面的重載忽略了基類對于less仿函數(shù)的引入,因為CString具備比較運算符,我們可以使用默認的less仿函數(shù),在這里映射為comp。好了,我們可以聲明新的hash_map對象如下:

          hash_map<CString, int, CString_hash_compare> CStringHash;

     其余的操作一樣一樣的。

     下來就說說對于自定義對象的使用方法:首先定義
     
          struct IHashable
          {
               virtual unsigned long hash_value() const = 0;
               virtual bool operator < (const IHashable& val) const = 0;
               virtual IHashable& operator = (const IHashable& val) = 0;
          };
     
     讓我們自寫的類都派生自這里,有一個標準,接下來定義我們的類:
     
          class CTest : public IHashable
          {
          public:
               int m_value;
               CString m_message;
          public:
               CTest() : m_value(0)
               {
               }
           
               CTest(const CTest& obj)
               {
                    m_value = obj.m_value;
                    m_message = obj.m_message;
               }
          public:
               virtual IHashable& operator = (const IHashable& val)
               {
                    m_value   = ((CTest&)val).m_value;
                    m_message = ((CTest&)val).m_message;
                    return(*this);
               }
           
               virtual unsigned long hash_value() const
               {
                    // 這里使用類中的m_value域計算hash值,也可以使用更復雜的函數(shù)計算所有域總的hash值
                    return(m_value ^ 0xdeadbeef 
               }
           
               virtual bool operator < (const IHashable& val) const
               {
                    return(m_value < ((CTest&)val).m_value);
               }
          };
     
     用這個類的對象做為hash索引準備工作如下,因為接口中規(guī)定了比較運算符,所以這里可以使用標準的less仿函數(shù),所以這里忽略:
     
          template<class _Tkey>
          class MyHashCompare : public hash_compare<_Tkey>
          {
          public:
               size_t operator()(const _Tkey& _Key) const
               {
                    return(_Key.hash_value());
               }
           
               bool operator()(const _Tkey& _Keyval1, const _Tkey& _Keyval2) const
               {
                    return (comp(_Keyval1, _Keyval2));
               }
          };
           
     下來就這樣寫:
     
          CTest test;
          test.m_value = 123;
          test.m_message = "This is a test";
     
          MyHash[test] = 2005;
           
          int val = MyHash[test];
     
     可以看到正確的數(shù)字被返回。
     
     三、關(guān)于hash_map的思考:
     
     1、性能分析:采用了內(nèi)聯(lián)代碼和模版技術(shù)的hash_map在效率上應該是非常優(yōu)秀的,但我們還需要注意如下幾點:
     
     * 經(jīng)過查看代碼,字符串索引會比簡單類型索引速度慢,自定義類型索引的性能則和我們選擇hash的內(nèi)容有很大關(guān)系,簡單為主,這是使用hash_map的基本原則。
     * 可以通過重寫hash_compair仿函數(shù),更改里面關(guān)于桶數(shù)量的定義,如果取值合適,也可以得到更優(yōu)的性能。如果桶數(shù)量大于10,則牢記它應該是一個質(zhì)數(shù)。
     * 在自定義類型是,重載的等號(或者拷貝構(gòu)造)有可能成為性能瓶頸,使用對象指針最為索引將是一個好的想法,但這就必須重寫less仿函數(shù),理由同使用字符串指針作為索引。

posted on 2008-01-12 18:31 小果子 閱讀(9710) 評論(0)  編輯 收藏 引用 所屬分類: 學習筆記
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            久久久av水蜜桃| 美女诱惑黄网站一区| 亚洲精品你懂的| 久久精品国产91精品亚洲| 国产亚洲一区二区三区| 久久欧美中文字幕| 久久综合色影院| 亚洲精品护士| 正在播放欧美视频| 国产日韩在线一区| 免费观看亚洲视频大全| 欧美jizzhd精品欧美喷水| 亚洲六月丁香色婷婷综合久久| 亚洲美女毛片| 国产一区二区精品丝袜| 欧美大片免费观看在线观看网站推荐| 欧美精品国产| 欧美一区二区三区在线| 久久精品一区二区国产| 亚洲精品在线二区| 午夜精品福利一区二区蜜股av| 一区二区三区在线观看国产| 亚洲高清不卡av| 国产精品视频大全| 欧美aa在线视频| 国产精品高潮在线| 欧美激情无毛| 国产一区二区三区黄视频| 欧美国产一区二区三区激情无套| 欧美视频精品在线| 快she精品国产999| 欧美午夜视频| 亚洲福利视频免费观看| 国产精品久久久久久久久久三级| 狂野欧美激情性xxxx| 欧美三级黄美女| 欧美成人性生活| 国产农村妇女精品| 亚洲韩国日本中文字幕| 国产自产精品| 亚洲深夜福利在线| 亚洲美女黄色| 久久综合狠狠综合久久激情| 性久久久久久久久久久久| 欧美激情亚洲| 欧美电影资源| 国产性猛交xxxx免费看久久| 99精品视频免费观看视频| 激情一区二区三区| 欧美伊人久久久久久久久影院| 亚洲午夜久久久| 欧美刺激午夜性久久久久久久| 久久久久一区二区| 国产婷婷一区二区| 亚洲一区免费网站| 亚洲欧美日韩国产另类专区| 欧美xart系列在线观看| 美女任你摸久久| 狠狠色丁香婷婷综合久久片| 亚洲午夜免费视频| 亚洲一区二区综合| 欧美午夜精品久久久久免费视| 亚洲激情黄色| 99国产一区| 欧美欧美在线| 99精品免费视频| 亚洲一区二区三区四区中文| 欧美激情一区三区| 亚洲精品在线视频| 夜夜爽www精品| 欧美日韩国产页| 一区二区精品在线观看| 亚洲综合视频在线| 国产欧美 在线欧美| 香蕉久久夜色精品| 久久这里有精品15一区二区三区| 国产小视频国产精品| 久久超碰97中文字幕| 久热精品视频| 亚洲精品少妇30p| 欧美日韩综合视频| 亚洲欧美日韩国产综合| 久久黄色小说| 亚洲高清不卡在线观看| 欧美成人dvd在线视频| 亚洲精品日韩在线| 亚洲欧美激情一区二区| 国产欧美一区二区精品秋霞影院| 欧美一区二区免费观在线| 久久婷婷激情| 99re成人精品视频| 国产日产精品一区二区三区四区的观看方式 | 免费观看30秒视频久久| 在线免费观看欧美| 欧美精品在线一区二区三区| 99国产精品| 久久久精彩视频| 在线观看亚洲视频啊啊啊啊| 欧美电影在线观看| 亚洲欧美日本视频在线观看| 欧美一区二区在线视频| 亚洲国产免费| 国产欧美 在线欧美| 久色婷婷小香蕉久久| 日韩亚洲视频| 欧美成人一品| 亚洲欧美精品中文字幕在线| 国产一区二区三区不卡在线观看| 欧美电影在线免费观看网站| 亚洲在线成人精品| 亚洲破处大片| 久久影视三级福利片| 一区二区高清在线| 在线高清一区| 国产欧美日韩视频| 欧美区一区二| 看欧美日韩国产| 午夜在线电影亚洲一区| 亚洲人成在线观看| 欧美 亚欧 日韩视频在线| 香蕉亚洲视频| 这里只有精品视频在线| 在线观看日韩一区| 国产一区视频网站| 国产精品户外野外| 欧美日韩午夜| 欧美激情亚洲一区| 欧美一区二区啪啪| 亚洲一区二区三区精品在线| 亚洲人成在线观看一区二区| 免费一区视频| 美国成人直播| 久久成人18免费网站| 亚洲午夜未删减在线观看| 亚洲精品视频免费在线观看| 在线观看免费视频综合| 国产日韩精品在线| 国产欧美一区二区三区国产幕精品| 欧美人与禽猛交乱配| 乱人伦精品视频在线观看| 久久黄色级2电影| 久久精品2019中文字幕| 亚洲欧美一区二区激情| 亚洲一区国产视频| 亚洲一区精品视频| 亚洲欧美色一区| 亚洲在线免费观看| 亚洲在线视频网站| 亚洲一区二区三区在线观看视频 | 欧美亚洲色图校园春色| 在线亚洲自拍| 亚洲综合色婷婷| 欧美一区二区三区日韩视频| 亚洲一二三四区| 性做久久久久久| 久久精品成人一区二区三区| 欧美制服第一页| 久久久久国产一区二区三区| 久久久久这里只有精品| 男人的天堂亚洲| 亚洲精品免费观看| 中文一区字幕| 欧美在线国产| 欧美69wwwcom| 国产精品theporn| 国产偷国产偷精品高清尤物| 精品不卡在线| 99这里只有久久精品视频| 亚洲夜间福利| 老司机精品导航| 亚洲卡通欧美制服中文| 亚洲天堂av在线免费| 欧美一区亚洲| 欧美黄色免费| 国产午夜精品理论片a级大结局| 国产在线拍揄自揄视频不卡99| 亚洲大胆人体视频| 一区二区三区av| 久久久久一本一区二区青青蜜月| 欧美高清视频一二三区| 一本色道久久精品| 久久九九久精品国产免费直播| 欧美精品v日韩精品v国产精品| 国产精品日韩电影| 在线看无码的免费网站| 亚洲午夜高清视频| 美女露胸一区二区三区| 99热精品在线观看| 另类av一区二区| 国产模特精品视频久久久久| 91久久国产自产拍夜夜嗨| 亚洲欧美综合| 亚洲精品乱码久久久久久蜜桃麻豆| 亚洲欧美日韩中文在线制服| 欧美大片一区| 国产最新精品精品你懂的| 在线一区二区三区做爰视频网站| 美女国内精品自产拍在线播放| 在线一区亚洲| 欧美伦理一区二区|