• <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
                眼下新的GUI Framework的第一版也就只剩下3個控件了。雖然之前說過要開發一個理論上是P2P上的遠程對象交互協議、要開發一個窗口設計器、還要開發一個LALR Parser GUI作為GUI Framework的demo。我想這也是一個大的工程,對于我一個人來說。但是今天的一個想法終于把這三個東西串了起來。

                想必大家MFC用得很囧吧。Linux下面開發C++反正所有選擇相比起當年的Borland C++Builder來說都是很爛的,那就不說了。Windows下面開發C++是哭笑不得。C++ Builder雖然想法是好的,其實我也不介意他用Delphi的VCL,只是編譯器的bug實在是太多了。新的C++Builder連試用版的安裝程序都有問題,于是徹底失去希望了。現在RAD也就剩下MFC一個了。說實話我以前做游戲、做軟件渲染器到現在做編譯器做什么什么的,實際上都是類似庫或者是中間件的,跟RAD一點關系都沒有。只不過我仍然非常喜歡RAD這樣的開發方式。但是MFC那個樣子實在是RAD不起來啊,所以我干脆揭竿而起,另做一個了。至于將來前途怎么樣我就不管了,至少得先讓自己爽起來再說。

                為什么我那么強調窗口設計器呢?其實可以大家可以開個C#,嘗試做一下我以前那個破IDE的界面。這樣的話窗口設計器會給你一份代碼,藏在XXForm.Designer.cs底下,然后寫幾行代碼把東西當prototype跑起來。然后你再用MFC做一遍。現在VC++ 9.0對MFC的支持其實也是很漂亮的,只不過量變引起不了質變而已。做完了之后比較一下哪個比較囧(指的僅僅是開發過程,不要拿效率說事兒,那點破界面慢一點無所謂)。

                現在我揭竿而起重頭來了一次,就等于給你.NET的System.Windows.Forms一樣,有類庫沒有界面編輯器。如果你想做一個界面出來的話就要自己親手寫一個XXForm.Designer.cs出來。這個其實比MFC更囧,也令我自己更加不爽。要是我自己做的東西連我自己用著都不高興的話那就太沒意思了,所以得來一個那樣的設計器才行。

                話說到這里,其實VL++這套類庫(除了GUI還有很多其他東西,用了的話連STL都免了)文件結構復雜,每一次使用都要重新一個一個添加,也是很不爽的。因此至少窗口設計器也要自動把這些該加進去的文件添加到vcproj不是么。但是VL++并不僅僅是一個GUI Framework啊,至少還能寫編譯器是吧。自己做了一個Syngram,直接在C++里面寫左遞歸文法,用起來也挺爽的。當然爽不是爽在能寫文法,而是爽在這樣做,編譯器遇到了大的變化也非常容易改,傳說中的解耦啊。Vczh Free Script 1.0只是一個支持閉包的東西,后來大刀闊斧修改了,就變成同時支持很多個編程范式的腳本語言了。多虧了Syngram啊,改語法真是不費吹灰之力。既然我要弄一個GUI工具來寫編譯器,那么吧兩個工具整合在一起,就是一個很自然的想法了。再加上未來有空的話還要做一個遠程對象交互協議,也是很需要GUI工具幫忙的。

                于是呢,雖然工程量很大,但是我們來展望一下。現在,自己需要開發一個系統的客戶端,這個客戶端需要跟遠程的數據庫打交道,同時還要支持大量的配置。那怎么辦呢?首先,打開這個工具,連接到一個剛剛建立好的vcproj上面,然后就拖控件了。拖完了之后就是一個prototype了,一跑覺得不錯。現在,從遠程的機器那邊拿到一個使用遠程對象交互協議的接口說明,添加到這個工具里面,這個工具就自動產生了客戶端的代碼,讓你可以像調用一個類一樣跟遠程的機器打交道(像SOA?我覺得不像,我也不想像。像WCF?雖然概念類似,不過既然我不做SOA,那就不像了)。最后一步要配置。現在配置都寫DSL啊。所謂的DSL就是面向特定領域的特殊語言。編譯器不會寫?沒關系,還是那個工具,新建一個編譯器,拖幾個文法出來,搞一搞,呀,代碼出來啦。用這個生成以后的代碼寫寫后端,一個DSL就有啦。

                嗯嗯,雖然很理想化,但至少這玩意兒作為一個原型存在,也是挺好玩的。不過呢,可能要花很長時間,這個計劃也不是穩定的,得看未來發生了些什么事情。不過最少那個做編譯器的玩意兒還是要的。ANTLR這個LL(k)都有了,我Syngram好歹也是LR(k),不做就不爽啦。
            posted on 2008-08-19 09:51 陳梓瀚(vczh) 閱讀(1804) 評論(5)  編輯 收藏 引用 所屬分類: 其他

            評論:
            # re: 關于VL++輔助C++程序設計的設想 2008-08-19 10:35 | jetricy
            不管3721先sf,
            分布式的做編譯器的環境?
            我暫時還是個對編譯器有興趣的外行,啥時候搞一個像樣的LR(K)還是比較口水的  回復  更多評論
              
            # re: 關于VL++輔助C++程序設計的設想 2008-08-19 15:35 | foxtail
            慢慢玩吧 有的你玩了  回復  更多評論
              
            # re: 關于VL++輔助C++程序設計的設想 2008-08-19 19:42 | 空明流轉
            去吧去吧,先搞吧。其實我用了YACC覺得也還行,生成現在配合構建腳本還算湊合。  回復  更多評論
              
            # re: 關于VL++輔助C++程序設計的設想[未登錄] 2008-08-20 05:34 | missdeer
            做IDE,有意思,我喜歡  回復  更多評論
              
            # re: 關于VL++輔助C++程序設計的設想 2008-08-23 23:58 | dell
            Windows下面開發C++的確很受折磨。  回復  更多評論
              
            国产aⅴ激情无码久久| 成人资源影音先锋久久资源网| 日本精品久久久久中文字幕8| 久久久无码一区二区三区| 国产成人久久精品一区二区三区 | 久久精品一本到99热免费| 久久精品亚洲一区二区三区浴池| .精品久久久麻豆国产精品| 人妻精品久久久久中文字幕 | 成人综合伊人五月婷久久| 久久青青草原国产精品免费| 天天做夜夜做久久做狠狠| 久久婷婷五月综合国产尤物app | 99久久国产宗和精品1上映 | 久久夜色精品国产噜噜亚洲AV| 久久精品成人免费看| 久久久久久久久久久久久久| 国产成人久久精品激情| 人妻无码久久精品| 91精品国产91热久久久久福利| 久久精品国产男包| 精品久久久久久久久久久久久久久| 久久精品国产亚洲AV久| 亚洲国产成人精品91久久久| 久久精品国产亚洲AV香蕉| 狠狠色狠狠色综合久久| 精品99久久aaa一级毛片| 91精品国产91久久久久福利 | 国产精品青草久久久久福利99| 看久久久久久a级毛片| 成人久久免费网站| 亚洲欧美精品一区久久中文字幕| 996久久国产精品线观看| 久久夜色精品国产噜噜噜亚洲AV | A狠狠久久蜜臀婷色中文网| 久久精品国产久精国产果冻传媒| 亚洲精品国产自在久久| 久久无码AV中文出轨人妻| 久久亚洲AV成人无码软件| 久久亚洲sm情趣捆绑调教| 亚洲欧美日韩久久精品第一区|