• <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>
            posts - 76,  comments - 621,  trackbacks - 0
            首先說,這篇文章是很久很久很久以前寫的,后來覺得沒啥技術(shù)含量,就沒發(fā)。今天放到這兒賺個眼球,主要目的還是征名,CPPBLOG網(wǎng)友一定要給力哦!

            征名:

            1. LiteEdit
            2. EditLite
            3. EverEdit
            4. EditWin
            5. MegaxEdit

            正文:
            -------------------------------------------------------------------------------------
            1. 什么是代碼自動完成1

              首先我們先來下個定義.不要小瞧這個,沒有這個定義,我們很容易迷失在功能的海洋之中.所謂代碼自動完成既是

              在用戶輸入或者修改的時候,能夠根據(jù)光標前后位置的文本信息, 從[事先準備好]的查找表中找出最匹配的過程.

              注意:我們在這里用了[事先準備好]這個詞.

            2. 難點分析

             A). 怎么查找?
             B). 從什么樣的表中查找?
             C). 內(nèi)存占用怎么樣?
             D). 如何快速的顯示出最匹配的結(jié)果?

             我想上面的幾個問題是大多數(shù)人的第一印象.確實,在我做這項工作之前,我嘗試了寫了幾個數(shù)據(jù)結(jié)構(gòu)來表達這樣的操作.

             什么三叉,二叉樹啊,可是最后發(fā)現(xiàn)都比較麻煩。

             不過,這些嘗試讓我覺得我寫的東西像個東西...什么呢? 這不就是個數(shù)據(jù)庫查詢嘛!!

             經(jīng)過一番周折(其間過程不述), 選用了sqlite3作為數(shù)據(jù)庫,關(guān)于sqlite3是什么,本文不作具體描述.

             那么上面的幾個難點就迎刃而解了.我們來看一下.

             A). 怎么查找?

             這個就簡單多啦, select * from table where keyword like 'hint%', 其中的hint就是用戶輸入或者修改的前后文文本信息.

             B). 從什么樣的查找表中查找?

             不管了,當然是數(shù)據(jù)庫.

             C). 內(nèi)存占用怎么樣?

             這個....我測試,一個表里面5萬條數(shù)據(jù),嵌入到程序之中后,內(nèi)存增加2M-3M左右.

             D). 如何快速的顯示出最匹配的結(jié)果?

             因為使用了數(shù)據(jù)庫,所以只顯示頭幾條就可以了.當然可以分頁顯示全部拉.因為sqlite支持limit語句.

             到了這兒,我們可以知道上面的幾個難點都不是難點了,甚至很Easy.

             不過,有一個問題,加入數(shù)據(jù)庫當中有好幾萬條甚至數(shù)十萬條,那么怎么辦呢?

             告訴你,沒有解決辦法!

             不過,我們要學會避開這些問題.比如,筆者做了一個可以根據(jù)用戶的輸入即時提示用戶可能輸入的單詞的Sample,包含常用的單詞,分詞,復數(shù),大約有10萬個左右吧.

             在我的程序中,甚至Debug版本中,都可以即時的顯示出來,不管你輸入多塊,還有一點就是內(nèi)存占用只增加了幾百K. Why?

             呵呵,其實很簡單,我創(chuàng)建了26張表. 聰明的讀者應(yīng)該馬上猜到了, 開頭為a的單詞放到一張表,開頭為b的單詞放到另一張表,其實就是一個簡單的hash,寫查詢的時候,這樣.

             sprintf( sql, "select word from %c_wordlist where word like '%s%%' limit 0, 10", buf[0], buf );

             效果不錯哦~~~`

             采用上面的做法,你可以想SourceInsight那樣,把一個庫,或者整個windows sdk掃描出來做好符號庫,進行簡單的自動完成...hahahaha

             選用數(shù)據(jù)庫的最大的優(yōu)點是可擴展性極佳.

            3).比較麻煩的一點: 如何完成文件內(nèi)的詞匯?

             2)上面說的都是事先準備好的表. 3)所提及的則是根據(jù)該文件要動態(tài)生成的表.

             其實上面兩者都是事先準備好的表,只不過一個狹義的,一個是廣義的而已.

             說它比較麻煩,因為沒做過的都會有個直觀思路,就是掃描整個文件,然后放入數(shù)據(jù)庫中就完事了啊.

             其實不然,直接掃描時最偷懶的做法,也是最有效的.
             
             在這里,我給一個簡單的解決方案,不過還沒沒來得及去寫.

             方案如下:

             在做詞法分析的時候,我們都會分析出來一些既不是關(guān)鍵字也不是字符串或者其它的state的[單純的文字].....懂了嗎?這些單純的

             文字就是我們要可能自動完成的詞匯.

             這樣,我們在分析的時候,只要把[ 詞匯->文件->代碼行 ]這樣的信息存入到指定的表中,就可以了.甚至只存入詞即可。

             添加行或者刪除行的時候,更新該表就可以了.

             在顯示的時候,因為一個文件可能關(guān)聯(lián)好幾個自動完成Database,那么設(shè)定好優(yōu)先級,本文件內(nèi)的很顯然具有最高優(yōu)先級.其它要么顯示

             要么不顯示.要么只在注釋中顯示.....

             每隔一段時間就掃描一次文件,如果文件不是太大的話,效率應(yīng)該不錯。

            -----------------------------------------------------------------------

             后記,我曾經(jīng)做了一個sample,后來換電腦了,就不知道弄哪去了。
            posted on 2011-01-04 20:21 megax 閱讀(3050) 評論(26)  編輯 收藏 引用
            老男人久久青草av高清| 人妻无码精品久久亚瑟影视| 久久精品国产只有精品2020 | 91精品婷婷国产综合久久| 久久se精品一区二区影院| 午夜天堂精品久久久久| 久久国产精品免费一区| 久久婷婷成人综合色综合| 久久亚洲精品无码观看不卡| 久久久亚洲欧洲日产国码aⅴ| 久久综合伊人77777| 精品久久香蕉国产线看观看亚洲| 亚洲欧美日韩精品久久亚洲区| 久久精品一区二区三区不卡| 国产一区二区久久久| 久久久久99精品成人片三人毛片| 久久久噜噜噜久久熟女AA片| 国产免费久久精品99re丫y| 精品乱码久久久久久夜夜嗨| 久久国产精品-久久精品| 久久久久成人精品无码中文字幕 | 亚洲午夜无码AV毛片久久| 超级碰久久免费公开视频| 久久se精品一区二区| 久久精品欧美日韩精品| 囯产极品美女高潮无套久久久| 色悠久久久久久久综合网| 久久er国产精品免费观看8| 国产精品成人精品久久久| 亚洲成色999久久网站| 久久久九九有精品国产| www亚洲欲色成人久久精品| 东京热TOKYO综合久久精品| 一日本道伊人久久综合影| 久久无码高潮喷水| 国产亚洲精久久久久久无码77777| 久久精品中文无码资源站| 久久午夜无码鲁丝片秋霞| 久久综合久久自在自线精品自 | 久久综合久久久| 久久乐国产精品亚洲综合|