• <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>

            stevenyao

              C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
              22 隨筆 :: 1 文章 :: 67 評論 :: 0 Trackbacks
            工程大到一定程度,需要引入一個make工具了,CMake QMake都不錯。
            GUI庫是必須放到DLL的,因為用的人可能會寫很大的程序,本身就分多個dll,GUI封裝里不可避免會有些全局變量,那么GUI庫在DLL里才容易保證全局變量的唯一性。
            另外GUI里還很要解決多堆問題,就是在一個堆里分配也要回到這個堆去釋放,所以要避免模塊堆和線程堆的問題,用DLL就可以擁有模塊內(nèi)存池。
            GUI里會產(chǎn)生大量小對象,會有內(nèi)存碎片化問題導(dǎo)致性能問題,內(nèi)存池是十分必要的。
            對了,可以去看看新版本的 WPS和YY語音,都是用Qt寫的客戶端。
            我覺得沒必要自己再造個輪子了,可以考慮用 Qt。 c++,跨平臺,自帶2d渲染引擎比GDI+快,豐富的基礎(chǔ)類庫和算法庫,天生的Java Script腳本綁定。
            如果比較下常用的幾種 signal/slot實現(xiàn)的話,我覺得Qt的實現(xiàn)是最好的。

            boost的signal/slot 有一個很嚴重的問題,就是會導(dǎo)致編譯非常慢,你寫個小測試程序是不會感覺到的,如果在幾十個文件中使用的話,編譯時間會成倍增長,即使用并行編譯也是慢。都是模板搞的,boost的泛型用得太花哨了。

            Qt則完全沒有這個問題,而且執(zhí)行效率也還可以。
            個人認為 qmake的命令行更好用,尤其是項目多的時候,pro文件提供了更靈活的配置管理。
            qmake -project
            qmake -tp vc
            這樣開啟dep的時候不會崩潰嗎?
            Qt的Qt Plugin不錯,引出的是 QObject,可以動態(tài)加載和調(diào)用
            中國是一房一妻制
            re: 加快編譯速度[未登錄] 姚冬 2010-10-26 21:49
            更簡單便宜的方式是 換塊固態(tài)硬盤
            re: 加快編譯速度[未登錄] 姚冬 2010-10-26 21:49
            有更便宜簡單的方法,換塊固態(tài)硬盤即可。
            re: C++界面庫的抉擇[未登錄] 姚冬 2010-07-31 18:48
            @陳梓瀚(vczh)
            只有在少數(shù)極端的情況下,你才需要你的GUI程序跨平臺。你什么時候看見一個能用的C/C++寫的帶GUI軟件,可以在不用改代碼的情況下,兩邊都編譯的。

            嚴重同意
            re: C++界面庫的抉擇[未登錄] 姚冬 2010-07-31 18:46
            我用我的愚蠢了解QT的特性,謝謝各位
            re: C++界面庫的抉擇[未登錄] 姚冬 2010-07-29 18:25
            如果開發(fā)語言選擇C++的話,QT 無疑是最佳選擇。
            性能一點都不差,尤其是 GraphicView系統(tǒng),支持硬件加速哦

            跨平臺是沒得說,PC平臺通吃,被Nokia收購后 ,手機平臺也占了一半了。

            特別是 signal/slot 系統(tǒng),非常完美的C++下的回調(diào)和事件通知架構(gòu),MFC的消息映射簡直是杯具。

            如果說QT有什么缺點,就是運行庫有點大,靜態(tài)鏈接也有 1.5Mb,動態(tài)則接近10M。但是如果你想寫個中等規(guī)模的軟件,比如 2-30萬行源代碼,那么就不是問題了。QT是更適合寫大程序的。
            這要看你的產(chǎn)品的定位了,如果是希望產(chǎn)品普及度高,那么顯然選Symbian,因為Symbian的市場存量是最大的,Nokia即使再沒落,未來幾年Symbian仍然是銷量最大的智能機。

            如果你想做高端市場,那么顯然是 iPhone,因為Symbian在高端市場的失敗幾乎是注定了的。
            可以考慮 用 sigslot
            http://sigslot.sourceforge.net/
            就一個頭文件,很輕量的 signal/slot實現(xiàn)
            Qt4.7 的確會有QML,但是和樓主想做的還不太一樣。
            似乎更類似 Qt Graphic View,但是目前的Qt GraphicView還沒有豐富的Widget,而且UI效果也一般,要實現(xiàn)好看的效果還有很多工作要做。

            QT已經(jīng)有點太龐大了,而且不打算支持D3D(被Nokia收購的并發(fā)癥)了,如果樓主有興趣造福業(yè)界,我是很支持的。

            前端有豐富的Widget,華麗的Effect,后端有硬件加速的圖形系統(tǒng),XML的Layout,如果都能實現(xiàn)還是很完美的。

            其實如果 IPhone/mac不是用變態(tài)的Objective-c的話,就是我心中接近完美的那個輪子了。
            @Jim

            你用的是Windows 64位吧?那么應(yīng)該運行 B\win64\vc.bat
            很黄很污的网站久久mimi色 | 欧美亚洲色综久久精品国产| 中文字幕久久精品| 久久久久女人精品毛片| 久久综合丁香激情久久| 久久久青草久久久青草| 国产成人无码精品久久久久免费| 亚洲综合久久夜AV | 国产精品欧美久久久天天影视| 国产高清美女一级a毛片久久w | 中文字幕一区二区三区久久网站| 国产精品女同一区二区久久| 国产精品久久久久久久app| 久久综合给合久久狠狠狠97色| 久久精品无码免费不卡| 国产成人久久精品一区二区三区| 久久亚洲精品无码播放| 国产亚洲欧美成人久久片| 国内精品久久久久久99| 久久久久久久国产免费看| 久久99免费视频| 人妻无码αv中文字幕久久琪琪布 人妻无码久久一区二区三区免费 人妻无码中文久久久久专区 | 国产叼嘿久久精品久久| 77777亚洲午夜久久多人| 久久综合给合综合久久| 久久精品夜色噜噜亚洲A∨| 国产99精品久久| 国产午夜精品久久久久免费视| 大香伊人久久精品一区二区| 久久精品国产亚洲5555| 99久久国产亚洲高清观看2024| 狠狠色丁香久久综合婷婷| 久久av高潮av无码av喷吹| 亚洲人成精品久久久久| 久久无码AV中文出轨人妻| 久久人人爽爽爽人久久久| 久久精品这里只有精99品| 精品久久国产一区二区三区香蕉| 亚洲国产精品久久66| 国产精品美女久久久m| 2021精品国产综合久久|