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

            征名:

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

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

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

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

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

            2. 難點分析

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

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

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

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

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

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

             A). 怎么查找?

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

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

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

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

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

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

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

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

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

             告訴你,沒有解決辦法!

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

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

             呵呵,其實很簡單,我創(chuàng)建了26張表. 聰明的讀者應該馬上猜到了, 開頭為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ù)庫中就完事了啊.

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

             方案如下:

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

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

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

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

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

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

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

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

             后記,我曾經(jīng)做了一個sample,后來換電腦了,就不知道弄哪去了。
            posted on 2011-01-04 20:21 megax 閱讀(3030) 評論(26)  編輯 收藏 引用
            久久精品中文字幕有码| 国内精品伊人久久久久妇| 国产成人精品白浆久久69| .精品久久久麻豆国产精品| 99久久国产热无码精品免费| 久久久久久综合一区中文字幕| 国产叼嘿久久精品久久| 久久亚洲高清综合| 欧美熟妇另类久久久久久不卡| 2021久久国自产拍精品| 国产精品丝袜久久久久久不卡| 久久男人AV资源网站| 久久精品中文字幕无码绿巨人| 久久免费视频网站| 伊人久久大香线蕉AV色婷婷色| 99久久中文字幕| 一级做a爰片久久毛片免费陪 | 久久天天躁狠狠躁夜夜avapp| 久久精品一区二区三区不卡| 怡红院日本一道日本久久 | 亚洲狠狠婷婷综合久久久久 | 无码人妻精品一区二区三区久久久| 久久免费精品视频| 欧美大香线蕉线伊人久久| 青青草原综合久久大伊人导航| 久久99精品久久久久久久不卡| 久久人人爽人人爽人人片AV高清| 一本色道久久88加勒比—综合| 久久99精品国产自在现线小黄鸭| 超级97碰碰碰碰久久久久最新| 久久综合九色欧美综合狠狠| 亚洲午夜久久影院| 久久综合九色综合97_久久久| 无码人妻少妇久久中文字幕蜜桃 | 免费国产99久久久香蕉| 狠狠色婷婷综合天天久久丁香| 久久婷婷五月综合成人D啪| 2021国内久久精品| 久久久久亚洲AV无码观看| 人妻少妇精品久久| 伊人色综合久久天天网|