• <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) 閱讀(2509) 評論(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
            也該讓大腦休息一下呢!  回復  更多評論
              
            久久精品国产亚洲av麻豆色欲 | 久久精品国产免费一区| 精品国产乱码久久久久久人妻 | 久久久精品国产sm调教网站 | 国产精品欧美久久久久无广告| 国产2021久久精品| 一97日本道伊人久久综合影院| 亚洲国产精品高清久久久| 九九99精品久久久久久| 欧美精品一区二区久久| 欧美大香线蕉线伊人久久| 成人午夜精品久久久久久久小说| 久久精品免费全国观看国产| 韩国无遮挡三级久久| 少妇久久久久久被弄到高潮| 国产亚洲婷婷香蕉久久精品| 亚洲午夜久久久| 草草久久久无码国产专区| 99久久久国产精品免费无卡顿| 久久99国产一区二区三区| 97久久久精品综合88久久| 伊人色综合九久久天天蜜桃 | 色婷婷综合久久久久中文字幕| 国产精品久久亚洲不卡动漫| 97久久婷婷五月综合色d啪蜜芽| 99国内精品久久久久久久| 色欲综合久久中文字幕网| 久久综合鬼色88久久精品综合自在自线噜噜 | 久久99精品九九九久久婷婷| 国产精品一区二区久久| 久久婷婷国产综合精品| 精品久久久无码21p发布| 人妻中文久久久久| 久久这里有精品视频| 91精品国产91久久久久久青草| 国产韩国精品一区二区三区久久| 国内精品九九久久精品| 丁香色欲久久久久久综合网| 久久精品国产亚洲αv忘忧草| 99久久做夜夜爱天天做精品| 怡红院日本一道日本久久 |