• <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++的確很受折磨。  回復  更多評論
              
            伊人久久精品无码av一区| 久久精品亚洲中文字幕无码麻豆| 欧美日韩成人精品久久久免费看| 久久精品国产99久久丝袜| 亚洲国产一成人久久精品| 久久精品中文字幕久久| 国产高潮国产高潮久久久| 亚洲国产成人久久一区WWW| 亚洲国产精品久久久久婷婷软件| 天天影视色香欲综合久久| 久久精品aⅴ无码中文字字幕不卡| 午夜精品久久久久久| 99久久精品无码一区二区毛片| 成人久久免费网站| 亚洲综合伊人久久大杳蕉| 久久久久亚洲AV无码网站| 99久久精品国产免看国产一区| 久久亚洲私人国产精品vA| 日日躁夜夜躁狠狠久久AV| 久久大香香蕉国产| 久久最近最新中文字幕大全| 伊人久久精品线影院| 日韩欧美亚洲国产精品字幕久久久| 开心久久婷婷综合中文字幕| 欧美亚洲国产精品久久高清| 伊人久久精品无码二区麻豆| 久久久91精品国产一区二区三区 | 色综合久久无码中文字幕| 狠狠88综合久久久久综合网| 精品人妻伦九区久久AAA片69| 亚洲伊人久久成综合人影院| 亚洲AV无码1区2区久久| 国产精品欧美久久久久天天影视| 久久精品国产精品亚洲下载| 7777久久亚洲中文字幕| 久久人人添人人爽添人人片牛牛 | 久久免费视频一区| 99久久免费国产精品| 69国产成人综合久久精品| 囯产极品美女高潮无套久久久| 久久综合成人网|