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

            eXile 的專欄

            共5頁: 1 2 3 4 5 
            Qt中可以采用 QSignalMapper.

            void numberClicked(int id) {}

            QPushButton* button0;
            QPushButton* button1;

            QSignalMapper* map = new QSignalMapper(this);
            connect(button0, SIGNAL(clicked()), signalMapper, SLOT(map()));
            connect(button1, SIGNAL(clicked()), signalMapper, SLOT(map()));
            map->setMapping(button0, 0);
            map->setMapping(button1, 1);

            connect(map, SIGNAL(mapped(int)), this, SIGNAL(numberClicked(id)));
            @cexer
            呵呵,也許我沒有表達清楚,我說的“局限于native win32的思維方式”,是指局限于win32本身的GUI組件設計,而沒有利用OOP技術和模式進行更好的組件與消息封裝策略,也就不能消除win32 GUI 設計本身的復雜性。這種設計到頂,也不過是一個改良版的WTL(可以參考 http://www.winxgui.cn/)。當然,它可以適用在性能要求較高的場合,這個,取決于樓主的目標了。
            最成熟的 GUI 庫當然是Qt, 你的設計還不錯,不過感覺還是native win32 的思維方式,沒有呈現出更高介的抽象,
            re: utf8編碼轉換 eXile 2008-07-23 23:03
            @spirit
            我用的mingw, 沒有注意到這個問題, 但是由于VC平臺的iterator并不是原生指針,所以正確的寫法應該是 &ucs2_buf[0]
            A:封有什么理由嗎?
            B:封還需要理由嗎?
            A: 不需要嗎?
            B:需要嗎?
            A: 。。。。研究研究,干嗎這么認真呢?
            B:熟歸熟,亂說話一樣告你誹謗。
            re: C++代碼風格谷歌版 eXile 2008-07-01 17:59
            @true
            we only allow an approved subset of Boost features. Currently, only boost/compressed_pair.hpp is permitted
            目前,只允許使用 boost/compressed_pair.hpp, 等于沒有,
            而且這個compressed_pair只是為了優化結構布局,如果在謹慎地使用模板前提下,沒有多少價值。
            @haskell
            無非就是不透明指針或者虛函數
            @沙迦
            首先搞清楚以下概念:頭指針,頭結點,首元素指針
            對于半同步半異步模式也可以在線程間傳遞socket描述符來簡化處理,但這樣業務邏輯就不容易和底層IO脫離, 處理起來要麻煩一些, 我想的也不成熟,歡迎探討。
            BTW,已經找到了 lf.pdf 和 hs-ha.pdf , 看來要研讀一下....
            謝謝修正,沒有看過,不過對于簡單的LF模型確實是這樣的,因為它可以使用阻塞IO或者單獨select,處理起來比較簡單。
            對ACE的TP_Reactor沒有過深研究,boost::asio中的reactor也是‘領導者/跟隨者’模式,不過asio并不保證這一點,還得自己加鎖
            ACE的TP_Reactor 是基于‘領導者/跟隨者’模式,這里的探討主要是針對半同步半異步模式。不過要實現一個無鎖的handler,‘領導者/跟隨者’模式應該更容易一些?!?/div>
            re: 剖析Etwork網絡庫 eXile 2008-05-21 23:04
            我也是越來越不喜歡C++了,目前比較傾向于純C或Python。
            對于純C的網絡庫,可以試試 libevent 或 libev, 應該算是比較好的庫了。
            可以參考 boost::asio中的detail/win_fd_set, 很簡單
            我也碰到過, 通過 '自定義' 菜單可恢復.
            我的老是提示末知的IO設備, 不知道是什么東西的驅動不對...
            不會吧, cppexplore和我都給你說出錯誤在哪, 竟然還沒有發現....
            說到代碼規范, 從你這段代碼來看, 確實給人印象很差, 比如連續三個過于簡寫的變量命名, 讓人去猜測變量的含義, 這樣就不好了.
            除了基本的邏輯錯誤, 象 n && m1 這樣的比較, 說明細節不夠認真.
            說實話, 不象老程序員的作風啊...
            @陳梓瀚(vczh)
            你所寫的模板形式和xpressive的表達式模板并沒有太大的差別, 因為表達式模板最終生成的也是類似于這樣的東西.
            另外, 程序庫為了實現功能的全面性和通用性, 必然要損失一部分效率, 樓上的對此也不用大驚小怪, 還是要注意素質.....
            lz對鏈表的實現確實有點問題, 主要是對于鏈表頭結點的管理不對,所以在實現中有些錯誤.
            另外, 面試的題目應該是in place倒置,而不是deep copy, 頭結點應該是不變的,所以這個函數根本不應該有返回值, 這個題目本身也不夠嚴謹.
            boost::xpressive有兩種使用方式, 一種就是和boost::regex一樣的動態解析,一種是靜態解析,類似于boost::spirit .
            如果你使用的正則式是硬編碼的字符串(大多數情況下都是如此), 那么使用 xpressive的靜態解析具有更高的效率, 因為它的解析模板是在編譯期生成的.
            樓上的正解。在使用多重繼承時要注意對象的布局。
            re: MFC之初 eXile 2008-04-23 12:17
            @cppexplore
            同感。MFC純粹把C++當成“帶類的C”來用,什么面向對象,設計模式統統靠邊站。Microsoft的開發人員都是技術大牛,不知道他們對自己設計的MFC作何評價...
            re: 模板參數名命名慣例 eXile 2008-04-22 13:19
            我覺得作為開源的fans,應該更加注重版權的意識。
            re: 兩個小巧的開源解析庫 eXile 2008-04-16 15:04
            tinyxml只適合于讀寫XML配置文件時使用,雖然簡單,但是不滿足高效的要求。
            re: 對string類的思考 eXile 2008-04-11 17:24
            VC6 CString 的字符串也就是常見的引用計數, 象lz這種實現, 再配合一個好用的內存池, 應該是蠻不錯的.
            re: 單元測試PPT講義 eXile 2008-04-08 22:56
            雖然只是提綱,但講得還不錯!
            不知老兄有沒有研究過boost::asio的定時器定現, 好象用的也是select
            呵呵,一般情況下,你都應該使用any, 而variant為了提高那么一點點效率, 費的那個勁....
            如果要提高效率的話, 可以選擇 boost::shared_ptr<void>來代替any
            .......我來解釋一下吧,
            any與variant的最大區別在于效率, any內部實現中使用動態分配, 而variant內部使用棧式分配.
            variant為對象聯合, 比如說variant<int, std::string>, 你可以理解成下列結構: union { int v1; std::string v2; };
            re: VC6正在被拋棄 eXile 2008-03-15 13:05
            @萬連文
            其實靜多態的優勢就是運行效率高一點, 選擇靜多態還是動多態, 要看插件系統是基于源代碼重用,還是二進制重用, 以及對性能的要求如何.
            不過一個事實是:不用boost的人,一般對模板都了解不深, 我想這才是這個家伙態度大變的原因吧.
            re: GCC4.3... eXile 2008-03-14 13:46
            vs2008只有tr1, 并沒有實現c++0x, 要到VS10了, 根據MS的發布周期, 估計是VS2011?
            在現在gcc的mt_allocator實現中,有一個bug, 就是對一個計數器(_M_use)并沒有采用原子計數,這個計數器主要用來控制空閑鏈的長度,所以它并不會導致程序異常,但是可能會影響到程序性能,不過如果采用原子計數,則有另一個性能上的擔憂。這個問題直到最新的gcc4.3中才得到解決。
            @cppexplore
            謝謝指正,不過cppexplore這么快就把測試模型搞出來,厲害,應該用的是什么庫吧,Apache?
            這個設計到模板的兩次掃描機制,VC或BC的做法可以使編譯略微快一些,但是會對一些還沒有實例化的模板代碼中的語法錯誤視而不見,而GCC的做法更為穩妥一些,也是符合標準的的行為。
            呵呵,正是如此,UserAlloc可以使用一個全局的boost::pool來實現,所謂大pool套小pool, 不過如果object_pool設計時完全放棄destroy, 則可以取得更大的優化。
            這個倒不是問題,因為object_pool是可配置的, 它帶有一個模板參數UserAlloc, 可以自定義
            呵呵,不當之處,敬請原諒。
            “多次申請,一次釋放”的情況,比如說對于服務器而言,從收到一個包,到對這個包的處理完畢,則可視為內存的一個周期。不過有時候異步完成,再加上object_pool只能管理一種對象,又限制了這種使用。
            數據拷貝是不可避免的,而且一般對效率影響不大,主要還是內存管理上作一些優化,比如使用內存池。
            我覺得lz對object_pool 的設計理念和如何使用都存在理解上的錯誤, 特別是以下幾點:
            1) 構造函數只能執行默認構造函數
            2) 設計了destroy這個函數,而同時為了防止用戶遺漏掉這個調用,而又在內存池析構的時候進行了檢測回收
            3)為了這個目的而又不至于析構object_pool的時間復雜度是O(n平方)


            object_pool 主要著眼于“自動析構”,在沒有gc的情況下,達到提高效率和自動管理內存的目的。而且它也特別適合于“多次申請,一次釋放”的情況.所以它甚至是鼓勵你忽略使用destroy(從它的例子就可以看出來)。

            destroy函數并沒有提高復雜度,因為內部鏈表始終處于有序狀態(由于使用order_malloc,order_free),所以不論是逐個釋放,還是成批釋放,它的復雜度都是O(N)

            對于最后一個AutoFreeAlloc, 我碰巧也研究過, 其實對于你說的"沒有pool回收到allocator,以供下次繼續使用"的問題,它最近的實現中已經解決了.
            在c++ 標準庫實現SGI STL中還有一種內存池的實現, 就是用一系列固定長的內存池來實現一個不定長的內存池, 它曾經是gcc3中stl的默認實現, 但在gcc4中不再使用, 理由是在多線程情況下優化并不明顯, 線程鎖反而成為瓶頸. 所以有時候一個線程一個內存池也是一個選擇.
            @WXX
            其實lz所說的結構體指的把網絡數據看作是POD數據類型來處理, 這樣來簡化處理過程(當然在我看來, 這只能把處理過程搞得更復雜), 而序列化把網絡數據看作二進制流或文本流. 從這個角度來談論這個問題的.
            其實你的設計就是最簡單的序列化實現.
            不過用較好的序列化庫對于接收時就簡單多了:

            std::vector<std::string> user_names;
            in_archive ar(received_data, received_size);
            if (ar.serialize(user_names)) visit(user_names);

            在serialize函數里包含了各種異常情況處理, 比如錯誤的數據, 字符串長度異常,而像你的要完全自己處理, 那太復雜了, 這正是我所說的容易產生bug的地方.
            呵呵, 那就具體探討一下, 比如發送一個用戶名列表, 這是一個字符串的容器, 用序列化大致實現起來就是以下樣子:
            std::vector<std::string> user_names;
            archive ar;
            if (ar.serialize(user_names)) socket.send(ar.data(), ar.size());

            不知道你是怎么實現的, 歡迎探討.
            缺點就是拐彎抹角,代碼量大?
            我的結論恰恰相反, 使用序列化的最大好處是簡化編程, 以及將來的可擴展性,
            至于調試, 對于這種網絡程序,如果再加上多線程,是很難調試的,而這種你所說的結構體簡直是bug的溫床, 所以為了保證可靠性,一般都是用命令錄制回放來進行測試的.
            一定要有typename, 不然通不過編譯....
            剛才試了一下, 沒有問題, 我用的是VC2005 (SP1)
            正確的寫法,使用template關鍵字,應該改成這樣:

            template<class ThreadingModel>
            struct pool : private ThreadingModel
            {
            typedef typename ThreadingModel::template thread_safe_type<size_t>::result index_t;
            //other public members

            private:
            index_t first_free_;
            };
            Cavendish Qi 是Trolltech的,你跟人家宣傳這個。。。
            我的做法是為配置設定默認值,如果讀寫失敗,就取默認值。
            共5頁: 1 2 3 4 5 

            導航

            <2025年8月>
            272829303112
            3456789
            10111213141516
            17181920212223
            24252627282930
            31123456

            統計

            • 隨筆 - 36
            • 文章 - 0
            • 評論 - 192
            • 引用 - 0

            常用鏈接

            留言簿(18)

            隨筆分類

            隨筆檔案

            服務器編程

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            一本一本久久a久久综合精品蜜桃 一本一道久久综合狠狠老 | 久久99精品国产99久久| 久久ww精品w免费人成| 久久免费精品一区二区| 亚洲?V乱码久久精品蜜桃| 久久久久久国产精品免费无码| 亚洲狠狠久久综合一区77777 | 久久精品国产精品亚洲毛片 | 亚洲va国产va天堂va久久| 亚洲人成伊人成综合网久久久| 精品无码久久久久久午夜| 91精品国产91久久久久久蜜臀| 国产成人综合久久精品红| 伊人久久大香线蕉精品| 久久久久亚洲精品天堂| 久久综合久久美利坚合众国| 国产精品久久久久一区二区三区| 久久综合给久久狠狠97色| 中文成人久久久久影院免费观看| 中文字幕亚洲综合久久2| 精品久久久久中文字幕日本| 7777精品伊人久久久大香线蕉| 国产精品免费久久久久影院| 国产一区二区精品久久| 久久久久亚洲AV无码永不| 久久综合九色综合网站| 日韩欧美亚洲综合久久| 亚洲国产精品综合久久一线| 手机看片久久高清国产日韩| 久久av高潮av无码av喷吹| 久久久九九有精品国产| 久久久国产精品福利免费 | 国产精品99久久久精品无码| 热久久国产欧美一区二区精品| 国产精品免费久久久久影院| 国内精品久久久久久不卡影院| 久久99热狠狠色精品一区| 国产精品久久久久9999| 国产精品美女久久久久AV福利 | 久久亚洲国产成人精品无码区| 久久精品国产一区二区三区|