• <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) 閱讀(2510) 評論(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久久免费观看| 久久99久久无码毛片一区二区| 欧美日韩成人精品久久久免费看| 久久精品国产亚洲AV不卡| 久久强奷乱码老熟女网站| 亚洲熟妇无码另类久久久| 久久99精品国产99久久| 日韩AV毛片精品久久久| 国产产无码乱码精品久久鸭| 丁香五月综合久久激情| 狠狠色婷婷久久一区二区| 国产三级精品久久| 久久久女人与动物群交毛片| 久久免费大片| 99久久综合狠狠综合久久| 亚洲AV日韩精品久久久久| 亚洲综合久久夜AV | 欧美久久综合性欧美| 色欲综合久久躁天天躁蜜桃| 少妇被又大又粗又爽毛片久久黑人| 97久久精品无码一区二区天美| 亚洲国产成人精品女人久久久| 久久精品成人免费看| 久久国产亚洲精品无码| AV无码久久久久不卡蜜桃| 亚洲精品无码久久毛片| 热综合一本伊人久久精品| 久久久久久国产精品美女| 狠狠色综合久久久久尤物| 久久亚洲综合色一区二区三区 | 久久婷婷国产综合精品| 99久久精品免费国产大片| 久久亚洲精品人成综合网| Xx性欧美肥妇精品久久久久久| 精品久久久久香蕉网| 77777亚洲午夜久久多喷| 丁香色欲久久久久久综合网| 精品久久久久久无码不卡| 青青青青久久精品国产h久久精品五福影院1421 | 亚洲AV日韩AV天堂久久| 中文国产成人精品久久不卡|