• <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>
            隨筆-341  評論-2670  文章-0  trackbacks-0
                第三篇草稿講了泛型concept的概念,這篇最終稿可以確定Vczh Library++ 3.0的NativeX所要支持的泛型concept的比較精確的特性了。

                泛型的concept的概念還是比較清晰的,這次我們便通過一個例子來講解他。假如在NativeX里面實現(xiàn)一個列表,顯然因為NativeX只有指針,所以寫起來大概就是:
            1 generic<T>
            2 structure List
            3 {
            4   T* items;
            5   int count;
            6 }

                于是我們想寫一個函數(shù)判斷兩個List是否相等。因為NativeX現(xiàn)在已經(jīng)有模板函數(shù)了,所以我們很簡單的一個想法是,傳入兩個List<T>*,然后再傳入一個函數(shù)指針function bool(T,T),就可以寫出下面的函數(shù)了:
             1 generic<T>
             2 function bool ListEquals(List<T>* xs, List<T>* ys, function bool(T,T) comparer)
             3 {
             4   result=true;
             5   if(xs->count!=yx->count)
             6   {
             7     result=false;
             8   }
             9   else
            10   {
            11     variable int current=xs->count-1;
            12     while(current>=0)
            13     {
            14       if(!comparer(xs->items[current], yx->items[current]))
            15       {
            16         result=false;
            17         exit;
            18       }
            19       current--;
            20     }
            21   }
            22 }

                這個做法咋一看好像沒什么問題,但是如果我們要比較List<List<int>>怎么辦呢?我們可以先寫一個function bool IntEquals(int a, int b);,然后再寫一個function bool IntListEquals(List<T> a, List<T> b);,這個函數(shù)里面用IntEquals加上ListEquals<int>來實現(xiàn),最后將他傳進ListEquals<List<int>>。到了這里還好,如果我們還想比較List<List<double>>、List<List<char>>等等,我們就要被迫搞出很多函數(shù)了。而且最大的問題是,當我們寫好這么多東西以后,我們想實現(xiàn)一個Find函數(shù)來查找List里面的對象的話,面對List<List<int>>、List<List<double>>等等的東西,我們又得重新寫一次了……

                這個問題在面向?qū)ο蟮恼Z言里面都很容易做到,只需要在一個類里面實現(xiàn)operator==就可以了。那這兩種方法有什么區(qū)別呢?假設(shè)我們把C++里面的類去掉,那么我們會發(fā)現(xiàn),ListEquals<T>的comparer參數(shù)是通過T自動找到的,而不是我們自己傳進去的。因此如何設(shè)計一套可以從類型找到某一組函數(shù)的機制,就因為我們把模板函數(shù)加入NativeX語言(基本上就是C語言)而變成了一個必須實現(xiàn)的功能了。在這里我準備引入concept這個概念。concept跟C++0x的concept以及haskell的type class的概念基本一致。現(xiàn)在就讓我們逐步在NativeX里面實現(xiàn)這套機制。

                我們在這里面對的問題是給一些給定的類型(或泛型類型,譬如說List<T>)實現(xiàn)Equals函數(shù),然后每一個Equals函數(shù)里面如果需要其他類型U的Equals函數(shù),可以直接找到,而不需要我們自己傳進去。因此這個問題可以抽象為,某些類型具有可以被兩兩比較是否相等的能力。因此定義如下:
            1 generic<T>
            2 concept Eq
            3 {
            4   bool Equals(T a, T b);
            5 }

                當然這些函數(shù)不能直接生出來,因此我們對于想比較的每一個類型都需要給出相應(yīng)的Equals函數(shù)。下面的代碼為int類型定義了Equals:
             1 instance int : Eq
             2 {
             3   Equals = IntEquals;
             4 }
             5 
             6 generic<T>
             7 function bool IntEquals(int a, int b)
             8 {
             9   result=a==b;
            10 }

                每比較一次數(shù)字就得調(diào)用一次函數(shù),這個開銷還是比較大的。在NativeX的所有設(shè)施都做好之后,我會開始做指令級別的優(yōu)化,然后看看要不要實現(xiàn)自動判斷并inline的功能。有了int : Eq之后,我們就可以為List<T>也寫一個Eq了。如果我們給出了List<T>的Equals的話,為了使用這個Equals,T也必須有相應(yīng)的Equals函數(shù),于是我們可以寫:
            1 generic<T>
            2 instance List : Eq
            3   where T : Eq
            4 {
            5   Equals = ListEquals<T>;
            6 }

                最后就是實現(xiàn)ListEquals了,注意ListEquals函數(shù)內(nèi)部是如何拿到類型T的Equals函數(shù)的:
             1 generic<T>
             2   where T : Eq
             3 function bool ListEquals(List<T> xs, List<T> ys)
             4 {
             5   result=true;
             6   if(xs->count!=ys->count)
             7   {
             8     result=false;
             9   }
            10   else
            11   {
            12      variable int current=xs->count-1;
            13      while(current>=0)
            14      {
            15        if(!Eq<T>::Equals(xs->items[current], yx->items[current]))
            16        {
            17          result=false;
            18          exit;
            19        }
            20        current--;
            21      }
            22   }
            23 }

                這里引入了一個新的語法:Eq<T>::Equals,用于自動搜索自己dll或者其他dll實現(xiàn)的這個函數(shù)。搜索會在虛擬機里面完成,編譯器只負責(zé)提供符號,并檢查類型。因此就大功告成了。

                這個instance的設(shè)計基本上來源于Haskell的type class,其實跟C++0x的那個concept關(guān)系還是比較小,畢竟NativeX沒有類,C++有類,Haskell沒有類。當然其缺點是你不能在定義了Eq<List<T>>::Equals的同時,專門為Eq<List<bool>>::Equals定義一個特殊的版本,就如同C++的偏特化一樣,這個就過于復(fù)雜了。雖然偏特化在C++的用處非常大,而且也十分常用,但是在NativeX里面就因為NativeX的模板可以編譯成二進制而會因為找不到高性能的實現(xiàn)方法被砍掉。
            posted on 2010-07-13 04:26 陳梓瀚(vczh) 閱讀(3007) 評論(8)  編輯 收藏 引用 所屬分類: VL++3.0開發(fā)紀事

            評論:
            # re: Vczh Library++ 3.0之NativeX語言泛型最終稿 2010-07-13 19:17 | newcpper
            不走標準化的道路,學(xué)習(xí)起來有困難啊,呵呵  回復(fù)  更多評論
              
            # re: Vczh Library++ 3.0之NativeX語言泛型最終稿 2010-07-13 19:23 | newcpper
            你設(shè)計的庫 是完全是自己用就OK了?還是想讓大家都可用?  回復(fù)  更多評論
              
            # re: Vczh Library++ 3.0之NativeX語言泛型最終稿 2010-07-13 19:29 | 陳梓瀚(vczh)
            @newcpper
            新腳本語言,何來標準之說。不過話說回來NativeX與高級語言的關(guān)系,就如同C與匯編的關(guān)系一樣。我將會把更高級的語言(譬如javascript)編譯成NativeX,從而剩下大量的時間(因為從NativeX開始整套編譯、調(diào)試和執(zhí)行的流程都是一樣的),以遍測試并在上面實現(xiàn)更多的腳本語言。因此NativeX,如果你不是為你的腳本語言寫非常底層的庫的話,一般是用不到的。  回復(fù)  更多評論
              
            # re: Vczh Library++ 3.0之NativeX語言泛型最終稿 2010-07-13 19:30 | 陳梓瀚(vczh)
            @newcpper
            而且generic concept其實就是haskell的class,上面我有鏈接,那個還是很淺顯易懂的。  回復(fù)  更多評論
              
            # re: Vczh Library++ 3.0之NativeX語言泛型最終稿 2010-07-14 19:11 | newcpper
            哦,不好意思,我指的是Vczh Library++ 3.0,能寫篇文章說說這種類庫的設(shè)計思路嗎?大概看了一下文檔,感覺類的結(jié)構(gòu)還是不太清楚,另外,貌似程序的注釋不多哈。  回復(fù)  更多評論
              
            # re: Vczh Library++ 3.0之NativeX語言泛型最終稿 2010-07-15 01:49 | 陳梓瀚(vczh)
            @newcpper
            我很討厭在程序里面寫注釋的,除非實在太復(fù)雜(參見正則表達式)。設(shè)計思路的話我倒是寫在了我的博客里面:【http://www.shnenglu.com/vczh/archive/2009/10/09/98207.html】,文檔只是介紹如何使用,并不是介紹我是怎么想出來的。

            不過暫時還沒有編譯器那部分的介紹,因為我不打算在設(shè)計還處于容易變動的階段寫這些文檔,會寫了也白寫的。  回復(fù)  更多評論
              
            # re: Vczh Library++ 3.0之NativeX語言泛型最終稿 2010-07-16 00:04 | newcpper
            呵呵,注釋是給讀代碼的人寫的(可能是幾年后的自己),你不寫注釋,美帝的BOSS還不抓狂?  回復(fù)  更多評論
              
            # re: Vczh Library++ 3.0之NativeX語言泛型最終稿 2010-07-16 03:30 | 陳梓瀚(vczh)
            @newcpper
            M$怎么會招那些連代碼都讀不懂的人呢  回復(fù)  更多評論
              
            波多野结衣久久一区二区| 久久久久国产精品嫩草影院| 亚洲AV无码久久精品蜜桃| 浪潮AV色综合久久天堂| 久久国产精品99久久久久久老狼| 国产成人久久精品麻豆一区 | 精品国产热久久久福利| 人人狠狠综合久久亚洲| 久久夜色精品国产噜噜噜亚洲AV| 国产精品久久久天天影视| 要久久爱在线免费观看| 久久精品视频网| 漂亮人妻被中出中文字幕久久| 丰满少妇人妻久久久久久| 日本精品一区二区久久久| 久久影院综合精品| 亚洲美日韩Av中文字幕无码久久久妻妇| 色欲综合久久中文字幕网| 三级片免费观看久久| 国产成人综合久久久久久| 久久久久免费看成人影片| 久久丫忘忧草产品| 久久久久亚洲AV无码去区首| 久久成人精品视频| 国产精品久久亚洲不卡动漫| 久久精品国产免费观看三人同眠| 精品久久人人做人人爽综合| 久久精品国产一区| 东京热TOKYO综合久久精品| 2021国产精品久久精品| 一本色综合久久| 怡红院日本一道日本久久| 久久ZYZ资源站无码中文动漫| 国产精品成人久久久| 久久精品国产男包| 一日本道伊人久久综合影| 久久只有这精品99| 日产精品久久久久久久| 久久精品国产亚洲av麻豆蜜芽| 久久亚洲国产成人影院| 亚洲午夜久久久久久噜噜噜|