• <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
            也該讓大腦休息一下呢!  回復  更多評論
              
            久久久免费观成人影院| 国内精品久久久久久久97牛牛 | 一本久久免费视频| 精品久久久久久中文字幕大豆网| 无码人妻少妇久久中文字幕| 午夜人妻久久久久久久久| 国产精品青草久久久久婷婷| 久久国产综合精品五月天| 三级三级久久三级久久| 久久美女人爽女人爽| 久久久久久午夜精品| 91精品国产综合久久精品| 亚洲国产天堂久久久久久 | 国产精品久久久福利| 人人狠狠综合88综合久久| 国产精品久久久久AV福利动漫| 国产精品成人99久久久久91gav | aaa级精品久久久国产片| 伊人久久大香线蕉无码麻豆| 国产69精品久久久久777| 婷婷五月深深久久精品| 久久综合亚洲色HEZYO国产| 久久成人影院精品777| 人妻无码αv中文字幕久久| 久久亚洲2019中文字幕| 一本久久久久久久| 91久久精品91久久性色| 久久亚洲春色中文字幕久久久 | 99久久精品国产麻豆| 久久亚洲精品无码AV红樱桃| 久久精品中文无码资源站| 中文字幕无码久久精品青草| 日韩欧美亚洲综合久久影院Ds | 久久婷婷成人综合色综合| 中文国产成人精品久久不卡| 香蕉久久久久久狠狠色| 久久笫一福利免费导航| 中文字幕无码av激情不卡久久| 久久人人添人人爽添人人片牛牛| 蜜桃麻豆WWW久久囤产精品| 亚洲精品蜜桃久久久久久|