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組件設(shè)計，而沒有利用OOP技術(shù)和模式進行更好的組件與消息封裝策略，也就不能消除win32 GUI 設(shè)計本身的復雜性。這種設(shè)計到頂，也不過是一個改良版的WTL（可以參考
http://www.winxgui.cn/)。當然，它可以適用在性能要求較高的場合，這個，取決于樓主的目標了。
最成熟的 GUI 庫當然是Qt, 你的設(shè)計還不錯，不過感覺還是native win32 的思維方式，沒有呈現(xiàn)出更高介的抽象，
re: utf8編碼轉(zhuǎn)換 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只是為了優(yōu)化結(jié)構(gòu)布局，如果在謹慎地使用模板前提下，沒有多少價值。
re: Google App Engine！ eXile 2008-06-03 17:11
@haskell
無非就是不透明指針或者虛函數(shù)
@沙迦
首先搞清楚以下概念：頭指針，頭結(jié)點，首元素指針
對于半同步半異步模式也可以在線程間傳遞socket描述符來簡化處理，但這樣業(yè)務(wù)邏輯就不容易和底層ＩＯ脫離, 處理起來要麻煩一些, 我想的也不成熟，歡迎探討。
ＢＴＷ，已經(jīng)找到了 lf.pdf 和 hs-ha.pdf , 看來要研讀一下....
謝謝修正，沒有看過，不過對于簡單的ＬＦ模型確實是這樣的，因為它可以使用阻塞ＩＯ或者單獨select，處理起來比較簡單。
對ACE的TP_Reactor沒有過深研究，boost::asio中的reactor也是‘領(lǐng)導者/跟隨者’模式，不過asio并不保證這一點，還得自己加鎖
ACE的TP_Reactor 是基于‘領(lǐng)導者/跟隨者’模式，這里的探討主要是針對半同步半異步模式。不過要實現(xiàn)一個無鎖的handler，‘領(lǐng)導者/跟隨者’模式應該更容易一些。
我也是越來越不喜歡Ｃ＋＋了，目前比較傾向于純Ｃ或Python。
對于純Ｃ的網(wǎng)絡(luò)庫，可以試試 libevent 或 libev, 應該算是比較好的庫了。
可以參考 boost::asio中的detail/win_fd_set, 很簡單
我的老是提示末知的IO設(shè)備, 不知道是什么東西的驅(qū)動不對...
不會吧, cppexplore和我都給你說出錯誤在哪, 竟然還沒有發(fā)現(xiàn)....
說到代碼規(guī)范, 從你這段代碼來看, 確實給人印象很差, 比如連續(xù)三個過于簡寫的變量命名, 讓人去猜測變量的含義, 這樣就不好了.
除了基本的邏輯錯誤, 象 n && m1 這樣的比較, 說明細節(jié)不夠認真.
說實話, 不象老程序員的作風啊...
re: 正則表達式——一點小插曲 eXile 2008-05-09 23:27
@陳梓瀚(vczh)
你所寫的模板形式和xpressive的表達式模板并沒有太大的差別, 因為表達式模板最終生成的也是類似于這樣的東西.
另外, 程序庫為了實現(xiàn)功能的全面性和通用性, 必然要損失一部分效率, 樓上的對此也不用大驚小怪, 還是要注意素質(zhì).....
lz對鏈表的實現(xiàn)確實有點問題, 主要是對于鏈表頭結(jié)點的管理不對,所以在實現(xiàn)中有些錯誤.
另外, 面試的題目應該是in place倒置,而不是deep copy, 頭結(jié)點應該是不變的,所以這個函數(shù)根本不應該有返回值, 這個題目本身也不夠嚴謹.
re: 正則表達式——一點小插曲 eXile 2008-05-08 13:39
boost::xpressive有兩種使用方式, 一種就是和boost::regex一樣的動態(tài)解析,一種是靜態(tài)解析,類似于boost::spirit .
如果你使用的正則式是硬編碼的字符串(大多數(shù)情況下都是如此), 那么使用 xpressive的靜態(tài)解析具有更高的效率, 因為它的解析模板是在編譯期生成的.
re: MFC之初 eXile 2008-04-23 12:17
@cppexplore
同感。ＭＦＣ純粹把Ｃ＋＋當成“帶類的Ｃ”來用，什么面向?qū)ο螅O(shè)計模式統(tǒng)統(tǒng)靠邊站。Microsoft的開發(fā)人員都是技術(shù)大牛，不知道他們對自己設(shè)計的ＭＦＣ作何評價...
re: 模板參數(shù)名命名慣例 eXile 2008-04-22 13:19
我覺得作為開源的fans，應該更加注重版權(quán)的意識。
re: 兩個小巧的開源解析庫 eXile 2008-04-16 15:04
tinyxml只適合于讀寫ＸＭＬ配置文件時使用，雖然簡單，但是不滿足高效的要求。
re: 對string類的思考 eXile 2008-04-11 17:24
VC6 CString 的字符串也就是常見的引用計數(shù), 象lz這種實現(xiàn), 再配合一個好用的內(nèi)存池, 應該是蠻不錯的.
re: 單元測試PPT講義 eXile 2008-04-08 22:56
雖然只是提綱，但講得還不錯！
不知老兄有沒有研究過boost::asio的定時器定現(xiàn), 好象用的也是select
呵呵,一般情況下,你都應該使用any, 而variant為了提高那么一點點效率, 費的那個勁....
如果要提高效率的話, 可以選擇 boost::shared_ptr<void>來代替any
.......我來解釋一下吧,
any與variant的最大區(qū)別在于效率, any內(nèi)部實現(xiàn)中使用動態(tài)分配, 而variant內(nèi)部使用棧式分配.
variant為對象聯(lián)合, 比如說variant<int, std::string>, 你可以理解成下列結(jié)構(gòu): union { int v1; std::string v2; };
re: VC6正在被拋棄 eXile 2008-03-15 13:05
@萬連文
其實靜多態(tài)的優(yōu)勢就是運行效率高一點, 選擇靜多態(tài)還是動多態(tài), 要看插件系統(tǒng)是基于源代碼重用,還是二進制重用, 以及對性能的要求如何.
不過一個事實是:不用boost的人,一般對模板都了解不深, 我想這才是這個家伙態(tài)度大變的原因吧.
re: GCC4.3... eXile 2008-03-14 13:46
vs2008只有tr1, 并沒有實現(xiàn)c++0x, 要到VS10了, 根據(jù)MS的發(fā)布周期, 估計是VS2011?
re: 高性能服務(wù)器的多線程策略 eXile 2008-03-12 12:41
在現(xiàn)在gcc的mt_allocator實現(xiàn)中，有一個bug, 就是對一個計數(shù)器(_M_use)并沒有采用原子計數(shù)，這個計數(shù)器主要用來控制空閑鏈的長度，所以它并不會導致程序異常，但是可能會影響到程序性能，不過如果采用原子計數(shù)，則有另一個性能上的擔憂。這個問題直到最新的gcc4.3中才得到解決。
re: 高性能服務(wù)器的多線程策略 eXile 2008-03-06 22:36
@cppexplore
謝謝指正，不過cppexplore這么快就把測試模型搞出來，厲害，應該用的是什么庫吧，Apache？
re: GCC不能正確繼承模板類？ eXile 2008-03-03 13:48
這個設(shè)計到模板的兩次掃描機制，ＶＣ或ＢＣ的做法可以使編譯略微快一些，但是會對一些還沒有實例化的模板代碼中的語法錯誤視而不見，而ＧＣＣ的做法更為穩(wěn)妥一些，也是符合標準的的行為。
呵呵，正是如此，UserAlloc可以使用一個全局的boost::pool來實現(xiàn)，所謂大pool套小pool, 不過如果object_pool設(shè)計時完全放棄destroy, 則可以取得更大的優(yōu)化。
這個倒不是問題，因為object_pool是可配置的, 它帶有一個模板參數(shù)UserAlloc, 可以自定義
呵呵，不當之處，敬請原諒。
“多次申請，一次釋放”的情況，比如說對于服務(wù)器而言，從收到一個包，到對這個包的處理完畢，則可視為內(nèi)存的一個周期。不過有時候異步完成，再加上object_pool只能管理一種對象，又限制了這種使用。
數(shù)據(jù)拷貝是不可避免的，而且一般對效率影響不大，主要還是內(nèi)存管理上作一些優(yōu)化，比如使用內(nèi)存池。
我覺得lz對object_pool 的設(shè)計理念和如何使用都存在理解上的錯誤, 特別是以下幾點：
1） 構(gòu)造函數(shù)只能執(zhí)行默認構(gòu)造函數(shù)
２) 設(shè)計了destroy這個函數(shù)，而同時為了防止用戶遺漏掉這個調(diào)用，而又在內(nèi)存池析構(gòu)的時候進行了檢測回收
３）為了這個目的而又不至于析構(gòu)object_pool的時間復雜度是O(n平方）
object_pool 主要著眼于“自動析構(gòu)”，在沒有g(shù)c的情況下，達到提高效率和自動管理內(nèi)存的目的。而且它也特別適合于“多次申請，一次釋放”的情況.所以它甚至是鼓勵你忽略使用destroy（從它的例子就可以看出來）。
destroy函數(shù)并沒有提高復雜度，因為內(nèi)部鏈表始終處于有序狀態(tài)（由于使用order_malloc,order_free)，所以不論是逐個釋放，還是成批釋放，它的復雜度都是O(N)
對于最后一個AutoFreeAlloc, 我碰巧也研究過, 其實對于你說的"沒有pool回收到allocator，以供下次繼續(xù)使用"的問題,它最近的實現(xiàn)中已經(jīng)解決了.
在c++ 標準庫實現(xiàn)SGI STL中還有一種內(nèi)存池的實現(xiàn), 就是用一系列固定長的內(nèi)存池來實現(xiàn)一個不定長的內(nèi)存池, 它曾經(jīng)是gcc3中stl的默認實現(xiàn), 但在gcc4中不再使用, 理由是在多線程情況下優(yōu)化并不明顯, 線程鎖反而成為瓶頸. 所以有時候一個線程一個內(nèi)存池也是一個選擇.
@WXX
其實lz所說的結(jié)構(gòu)體指的把網(wǎng)絡(luò)數(shù)據(jù)看作是POD數(shù)據(jù)類型來處理, 這樣來簡化處理過程(當然在我看來, 這只能把處理過程搞得更復雜), 而序列化把網(wǎng)絡(luò)數(shù)據(jù)看作二進制流或文本流. 從這個角度來談?wù)撨@個問題的.
其實你的設(shè)計就是最簡單的序列化實現(xiàn).
不過用較好的序列化庫對于接收時就簡單多了:
std::vector<std::string> user_names;
in_archive ar(received_data, received_size);
if (ar.serialize(user_names)) visit(user_names);
在serialize函數(shù)里包含了各種異常情況處理, 比如錯誤的數(shù)據(jù), 字符串長度異常,而像你的要完全自己處理, 那太復雜了, 這正是我所說的容易產(chǎn)生bug的地方.
呵呵, 那就具體探討一下, 比如發(fā)送一個用戶名列表, 這是一個字符串的容器, 用序列化大致實現(xiàn)起來就是以下樣子:
std::vector<std::string> user_names;
archive ar;
if (ar.serialize(user_names)) socket.send(ar.data(), ar.size());
不知道你是怎么實現(xiàn)的, 歡迎探討.
缺點就是拐彎抹角，代碼量大?
我的結(jié)論恰恰相反, 使用序列化的最大好處是簡化編程, 以及將來的可擴展性,
至于調(diào)試, 對于這種網(wǎng)絡(luò)程序,如果再加上多線程,是很難調(diào)試的,而這種你所說的結(jié)構(gòu)體簡直是bug的溫床, 所以為了保證可靠性,一般都是用命令錄制回放來進行測試的.
re: VS 2005模板的一個問題及解決方案 eXile 2008-02-17 13:08
一定要有typename, 不然通不過編譯....
re: VS 2005模板的一個問題及解決方案 eXile 2008-02-17 13:07
剛才試了一下, 沒有問題, 我用的是VC2005 (SP1)
re: VS 2005模板的一個問題及解決方案 eXile 2008-02-17 00:49
正確的寫法，使用template關(guān)鍵字，應該改成這樣：
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的，你跟人家宣傳這個。。。
re: 濫用ini配置文件造成崩潰 eXile 2008-01-29 12:59
我的做法是為配置設(shè)定默認值，如果讀寫失敗，就取默認值。