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只是為了優化結構布局，如果在謹慎地使用模板前提下，沒有多少價值。
re: Google App Engine！ eXile 2008-06-03 17:11
@沙迦
首先搞清楚以下概念：頭指針，頭結點，首元素指針
re: Reactor模式中網絡事件分派探討 eXile 2008-05-23 12:39
對于半同步半異步模式也可以在線程間傳遞socket描述符來簡化處理，但這樣業務邏輯就不容易和底層ＩＯ脫離, 處理起來要麻煩一些, 我想的也不成熟，歡迎探討。
ＢＴＷ，已經找到了 lf.pdf 和 hs-ha.pdf , 看來要研讀一下....
re: Reactor模式中網絡事件分派探討 eXile 2008-05-23 12:07
謝謝修正，沒有看過，不過對于簡單的ＬＦ模型確實是這樣的，因為它可以使用阻塞ＩＯ或者單獨select，處理起來比較簡單。
re: Reactor模式中網絡事件分派探討 eXile 2008-05-22 22:47
對ACE的TP_Reactor沒有過深研究，boost::asio中的reactor也是‘領導者/跟隨者’模式，不過asio并不保證這一點，還得自己加鎖
re: Reactor模式中網絡事件分派探討 eXile 2008-05-22 22:21
ACE的TP_Reactor 是基于‘領導者/跟隨者’模式，這里的探討主要是針對半同步半異步模式。不過要實現一個無鎖的handler，‘領導者/跟隨者’模式應該更容易一些。
re: 剖析Etwork網絡庫 eXile 2008-05-21 23:04
我也是越來越不喜歡Ｃ＋＋了，目前比較傾向于純Ｃ或Python。
對于純Ｃ的網絡庫，可以試試 libevent 或 libev, 應該算是比較好的庫了。
可以參考 boost::asio中的detail/win_fd_set, 很簡單
我的老是提示末知的IO設備, 不知道是什么東西的驅動不對...
不會吧, cppexplore和我都給你說出錯誤在哪, 竟然還沒有發現....
說到代碼規范, 從你這段代碼來看, 確實給人印象很差, 比如連續三個過于簡寫的變量命名, 讓人去猜測變量的含義, 這樣就不好了.
除了基本的邏輯錯誤, 象 n && m1 這樣的比較, 說明細節不夠認真.
說實話, 不象老程序員的作風啊...
re: 正則表達式——一點小插曲 eXile 2008-05-09 23:27
@陳梓瀚(vczh)
你所寫的模板形式和xpressive的表達式模板并沒有太大的差別, 因為表達式模板最終生成的也是類似于這樣的東西.
另外, 程序庫為了實現功能的全面性和通用性, 必然要損失一部分效率, 樓上的對此也不用大驚小怪, 還是要注意素質.....
lz對鏈表的實現確實有點問題, 主要是對于鏈表頭結點的管理不對,所以在實現中有些錯誤.
另外, 面試的題目應該是in place倒置,而不是deep copy, 頭結點應該是不變的,所以這個函數根本不應該有返回值, 這個題目本身也不夠嚴謹.
re: 正則表達式——一點小插曲 eXile 2008-05-08 13:39
boost::xpressive有兩種使用方式, 一種就是和boost::regex一樣的動態解析,一種是靜態解析,類似于boost::spirit .
如果你使用的正則式是硬編碼的字符串(大多數情況下都是如此), 那么使用 xpressive的靜態解析具有更高的效率, 因為它的解析模板是在編譯期生成的.
re: MFC之初 eXile 2008-04-23 12:17
@cppexplore
同感。ＭＦＣ純粹把Ｃ＋＋當成“帶類的Ｃ”來用，什么面向對象，設計模式統統靠邊站。Microsoft的開發人員都是技術大牛，不知道他們對自己設計的ＭＦＣ作何評價...
re: 模板參數名命名慣例 eXile 2008-04-22 13:19
我覺得作為開源的fans，應該更加注重版權的意識。
re: 兩個小巧的開源解析庫 eXile 2008-04-16 15:04
tinyxml只適合于讀寫ＸＭＬ配置文件時使用，雖然簡單，但是不滿足高效的要求。
re: 對string類的思考 eXile 2008-04-11 17:24
VC6 CString 的字符串也就是常見的引用計數, 象lz這種實現, 再配合一個好用的內存池, 應該是蠻不錯的.
re: 單元測試PPT講義 eXile 2008-04-08 22:56
雖然只是提綱，但講得還不錯！
re: 【原創】系統設計之 定時器 eXile 2008-04-03 16:55
不知老兄有沒有研究過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?
re: 高性能服務器的多線程策略 eXile 2008-03-12 12:41
在現在gcc的mt_allocator實現中，有一個bug, 就是對一個計數器(_M_use)并沒有采用原子計數，這個計數器主要用來控制空閑鏈的長度，所以它并不會導致程序異常，但是可能會影響到程序性能，不過如果采用原子計數，則有另一個性能上的擔憂。這個問題直到最新的gcc4.3中才得到解決。
re: 高性能服務器的多線程策略 eXile 2008-03-06 22:36
@cppexplore
謝謝指正，不過cppexplore這么快就把測試模型搞出來，厲害，應該用的是什么庫吧，Apache？
re: GCC不能正確繼承模板類？ eXile 2008-03-03 13:48
這個設計到模板的兩次掃描機制，ＶＣ或ＢＣ的做法可以使編譯略微快一些，但是會對一些還沒有實例化的模板代碼中的語法錯誤視而不見，而ＧＣＣ的做法更為穩妥一些，也是符合標準的的行為。
re: 【原創】系統設計之 內存管理（三） eXile 2008-02-21 11:50
呵呵，正是如此，UserAlloc可以使用一個全局的boost::pool來實現，所謂大pool套小pool, 不過如果object_pool設計時完全放棄destroy, 則可以取得更大的優化。
re: 【原創】系統設計之 內存管理（三） eXile 2008-02-21 11:12
這個倒不是問題，因為object_pool是可配置的, 它帶有一個模板參數UserAlloc, 可以自定義
re: 【原創】系統設計之 內存管理（三） eXile 2008-02-21 10:48
呵呵，不當之處，敬請原諒。
“多次申請，一次釋放”的情況，比如說對于服務器而言，從收到一個包，到對這個包的處理完畢，則可視為內存的一個周期。不過有時候異步完成，再加上object_pool只能管理一種對象，又限制了這種使用。
數據拷貝是不可避免的，而且一般對效率影響不大，主要還是內存管理上作一些優化，比如使用內存池。
re: 【原創】系統設計之 內存管理（三） eXile 2008-02-20 23:15
我覺得lz對object_pool 的設計理念和如何使用都存在理解上的錯誤, 特別是以下幾點：
1） 構造函數只能執行默認構造函數
２) 設計了destroy這個函數，而同時為了防止用戶遺漏掉這個調用，而又在內存池析構的時候進行了檢測回收
３）為了這個目的而又不至于析構object_pool的時間復雜度是O(n平方）
object_pool 主要著眼于“自動析構”，在沒有gc的情況下，達到提高效率和自動管理內存的目的。而且它也特別適合于“多次申請，一次釋放”的情況.所以它甚至是鼓勵你忽略使用destroy（從它的例子就可以看出來）。
destroy函數并沒有提高復雜度，因為內部鏈表始終處于有序狀態（由于使用order_malloc,order_free)，所以不論是逐個釋放，還是成批釋放，它的復雜度都是O(N)
re: 【原創】系統設計之 內存管理 eXile 2008-02-18 18:39
對于最后一個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的溫床, 所以為了保證可靠性,一般都是用命令錄制回放來進行測試的.
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關鍵字，應該改成這樣：
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
我的做法是為配置設定默認值，如果讀寫失敗，就取默認值。