• <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
                接上一篇文章。自從昨天設計了NativeX語言的泛型之后,今天又對昨天的草稿做了一下修改。設計語言的語法總是這樣,首先對你自己的需求提出直接的解決方法,然后看看是不是有些新的概念跟其他概念可以合并起來變成更抽象的概念,而且又不會在實現上導致困難,也不會讓編譯器變的突然難寫許多。經過了昨天晚上和今天早上的思考,我決定簡化一下泛型的語法以及concept的內容。

                首先說語法上的。上一篇文章在定義泛型頭的時候采用了generic<type T1, type T2, concept C1, concept C2>這樣子的語法。本著盡量減少關鍵字的原則,我決定去掉type,變成generic<T1, T2, concept C1, concept C2>。原因是concept關鍵字還能用來定義一個契約,而type則毫無用處。而且一個契約有了concept關鍵字作開頭,也不會跟沒有type關鍵字的類型參數混淆。

                其次是concept。昨天定義了concept instance和concept series。其實總結到最后,concept instance無非就是concept series的一個特例。根據昨天的說法,把所有的instance都替換成series其實結果還是一樣的。唯一的區別就是concept series不允許在既不是concept定義所在的Assembly也不是特化所涉及類型的Assembly里面出現它的一個特化。如果單純去掉了concept instance的話顯然會帶來問題:我在AssemblyA處聲明了一個concept Sortable<T>之后,沒辦法在AssemblyB處聲明一個concept series IntSortable : Sortable<int>。因此某一些限制需要放寬一點:
                1、concept series的原始版本可以在一個既不包含concept聲明和也不包含涉及的類型聲明的地方聲明。
                2、concept series的特化版本則必須出現在包含concept聲明或者包含涉及類型聲明的地方聲明。

                那么其實series關鍵字也不需要了,因此會獲得下面的寫法:
             1 generic<T>
             2 concept GSortable
             3 {
             4   bool LessThan(T a, T b);
             5 }
             6 
             7 generic<T>
             8 instance Sortable : GSortable<T>
             9 {
            10   LessThan = BinaryLessThen<T>;
            11 }
            12 
            13 instance Sortable<int>
            14 {
            15   LessThan(a, b) = a < b;
            16 }

                operation和function的區分實際上沒什么大的價值,如果你真的需要一個函數指針的話,那就在參數傳進去好了。而且constant也沒什么必要,因為constant實際上是operation的一個特例,只是使用的時候需要多寫一個口號罷了。我們會看到上面定義concept其中的操作的兩個方法:指定函數和指定表達式。如果制定了表達是的話,那么該表達式將會被內聯(啊)。所以constant存在的價值也就不存在了。因此我們甚至連function、operation和constant的區分也消失了,所以在語法上更加得到了簡化。

                NativeX每一次引入一個新的特性的時候都是迫不得已而為之,而且一旦引入之后我總是力圖將該特性設計成跟其他所有的特性正交。例如這里的泛型,所有的東西都可以加上泛型,譬如結構體、全局變量、函數、契約和契約實例。所有的東西都可以是非泛型的,也可以是泛型的。有時候我們的確需要定義一個非泛型的concept,這其實也不是什么大問題。

                不過當前的語法還會遇到C++那經典的>>問題(一直到了C++0x才正式納入標準- -b)。這個問題有三種解決辦法,第一種是不允許寫成vector<vector<int> >,第二種是允許寫a>>b也允許寫a> >b(中間有個空格),第三種是跟VC++一樣一概支持。最后一個比較困難,第二個比較奇怪,第一個比較惡習。不過結合了各種因素之后,其實我覺得支持第二個倒是最簡單的辦法:你仍然可以寫出漂亮的代碼,而且你如果自己受得了a> >b而自己惡心自己的話,那也是你自己的事……

                至于其它問題,NativeX沒有逗號表達式,聲明NativeX的變量需要加上variable關鍵字,聲明NativeX的函數需要加上function關鍵字,所以全部迎刃而解。
            posted on 2010-06-13 23:50 陳梓瀚(vczh) 閱讀(2513) 評論(2)  編輯 收藏 引用 所屬分類: VL++3.0開發紀事

            評論:
            # re: Vczh Library++ 3.0之NativeX語言泛型草稿(二) 2010-06-14 03:22 | mm
            一天一篇真厲害!  回復  更多評論
              
            # re: Vczh Library++ 3.0之NativeX語言泛型草稿(二) 2010-06-14 03:24 | mm
            也該讓大腦休息一下呢!  回復  更多評論
              
            漂亮人妻被黑人久久精品| 狠狠色丁香婷婷综合久久来来去| 欧美激情精品久久久久久久九九九 | 麻豆精品久久久久久久99蜜桃| 精品一二三区久久aaa片| 国产精品久久久亚洲| 日韩中文久久| 国产精品99久久久久久人| 中文字幕精品无码久久久久久3D日动漫| 老男人久久青草av高清| 国产激情久久久久影院| 久久久精品2019免费观看 | 亚洲国产成人久久一区WWW| 无码人妻久久一区二区三区 | 精品无码久久久久久久动漫 | 久久精品国产一区二区三区| 亚洲成色www久久网站夜月| 日本精品久久久久久久久免费| 国产精品久久久久久影院| 久久受www免费人成_看片中文| 伊人久久大香线蕉精品| 麻豆AV一区二区三区久久 | 亚洲国产成人精品91久久久| 久久精品国内一区二区三区| 漂亮人妻被黑人久久精品| 波多野结衣久久一区二区| 亚洲Av无码国产情品久久| 国产精品成人久久久久三级午夜电影 | 97精品伊人久久大香线蕉app| 国产一区二区久久久| 亚洲精品无码久久久| 亚洲国产婷婷香蕉久久久久久| 国产毛片久久久久久国产毛片| 热久久国产精品| 国产69精品久久久久99| 久久久久人妻一区精品果冻| 国产一区二区三精品久久久无广告| 热99re久久国超精品首页| 国产亚洲精久久久久久无码AV| 久久久噜噜噜久久中文字幕色伊伊| 久久亚洲中文字幕精品一区四 |