国产一区二区高清不卡,久久久久久一区二区三区,久久黄金**

@OwnWaterloo
呵呵

這種寫法

template <typename S>
class C;

template <typename R>
class C<R (__stdcall)()>
{

};

發(fā)現(xiàn)通不過。。。

還有這個：

template <typename T>
class C;

template <typename U>
class C<SomeTraits<U>::Result>
{

};

偏特化的尖括號里不能進行摸板元運算？

re: C++ 下 Function 對象的實現(xiàn)（上）溪流 2011-01-19 00:59

@OwnWaterloo
呵呵，那玩意兒我本想改成一個博客客戶端，一直沒動。。。
可是，工作范圍以外，就更要玩感興趣的語言了呀~
我寫轉移文章的東西，不是為了轉移文章，是為了寫。
當然，碰到一些具有真實需求的并且有緊迫性的事情，那是要追求效率的。。。只不過這種狀況跟工作無異了

re: C++ 下 Function 對象的實現(xiàn)（上）溪流 2011-01-19 00:56

@OwnWaterloo
但是只要不要把返回值拆出來，就是可以的

template<typename F>
void call(F f ) { return f(); }

void __cdecl f() { printf("cdecl\n"); }
void __stdcall g() { printf("stdcall\n"); }

re: C++ 下 Function 對象的實現(xiàn)（上）溪流 2011-01-19 00:50

@OwnWaterloo
多學點自然是應該的，但我覺得不應該追求日常編程脫離C/C++啊。。。那是件多么可怕的事，關系到飯碗。當然不是歧視腳本語言什么的，但是從現(xiàn)狀看來，越來越多的人在用更加簡單的語言，業(yè)界最稀有的的還是C/C++的人啊。（vczh說的生存斗爭觀點我很贊同。）越簡單意味著入門越容易，競爭者多，于是想勝出就難了。所以我覺得往復雜方面靠的大方向還是要的。所以。。。用API不如造API，用輪子不如造輪子，不如用造輪子的輪子。。。臨了的時候，也許可以居高臨下的跟別人說：你，不就是會很多API么？這些API我都造過。你，不就是會用很多輪子嗎？這些輪子我都造過。你，不就是會用很多語言嗎？這些語言我也都造過。。。哈哈，扯淡了

re: C++ 下 Function 對象的實現(xiàn)（上）溪流 2011-01-19 00:33

@OwnWaterloo
bind的時候會遇到怎樣的情形我目前不知道。但是就 function 的階段來說，我剛剛自認為比較仔細地確認了代碼能夠跑的樣子：

void __cdecl f1(int)
{

}

void __stdcall f2(int)
{

}

int main()
{
Function<void (int)> g1(&f1);
Function<void (int)> g2(&f2);
g1(0);
g2(0);

return 0;
}

觀察匯編結果，f1的ret出來后有 add esp 4動作，f2的ret 4出來后沒有

re: C++ 下 Function 對象的實現(xiàn)（上）溪流 2011-01-19 00:24

@OwnWaterloo
歡迎聊天~~~

warning神馬的，感覺就是要見一次殺一次，不然絕對破窗效應。

“當需要這種靈活性時，直接把C++丟了，選其他動態(tài)類型語言來編程。”有一群糾結的人（當然不是我），他們的信仰就是用 C++ 做任何事，或者說他們的興趣就是用C++ 來做任何事，那怎么辦呢？呵呵。且不說個人興趣導向。從很理性的結果主義的角度考慮，這種時候確實得換，應該要換，但也不是每個這樣的場合都有條件換，比如團隊里沒有會python的且不想學python，但有一群蛋疼的Cpper，這種事情也會發(fā)生吧。

最后，你說你在教C？求教，求升華~！·^_^

re: C++ 下 Function 對象的實現(xiàn)（上）溪流 2011-01-19 00:17

@cexer
謝謝分享這么多想法。

給 handler 起名字確是刪除 handler 的好辦法，我可以不用糾結要不要用 typeid 啦。

另外關于你說的不同類型的handler的綁定，作為 Function，我覺得不該加入這樣的特性；作為GUI專用的Event，是可以接受有的特性的。

但是另一點疑問是，框架告訴用戶的規(guī)則——“返回 void 表示讓框架決定是否繼續(xù)處理，返回bool表示用戶想讓框架繼續(xù)處理或者拒絕用戶繼續(xù)處理”，與WTL的bHandled告訴用戶的——“設置bHandled用于指示框架是否繼續(xù)處理”相比，優(yōu)勢大嗎？都存在一種約定。而用返回void與bool的形式，可能僅僅是更加炫一點？

實現(xiàn)上，不管用戶看到的參數是怎樣的，框架最初獲得的肯定是 WPARAM 和 LPARAM，這樣，就算不修改 Function，似乎也可以在控件中給出不同的處理函數形式，例如給出一組重載的 OnClick：
OnClick(Function<void (int, int)>)
OnClick(Function<bool (int, int)>)
又例如給ClickEvent實現(xiàn)重載的operator+=？

前兩天我在猶豫框架要不要幫用戶解析 WPARAM、LPARAM，你的例子讓我堅定了想法，解析之！。。讓使用者不需要查 MSDN。。。或許做不到這種程度吧。

re: C++ 下 Function 對象的實現(xiàn)（上）溪流 2011-01-19 00:00

@OwnWaterloo
很多時候， C++ 程序員不是去考慮這種需求是否存在，實現(xiàn)這種需求的復雜度如何，維護代價如何。
僅僅是因為他們能，所以他們就要這樣做……
其實有時候，這些需求僅僅是美學上的，而不是技術上的。

“僅僅是因為他們能，所以他們就要這樣做……”有時候確實這樣，但一般實現(xiàn)代價一般很小的情況下才會出現(xiàn)這種沖動，想要順手做了。

re: C++ 下 Function 對象的實現(xiàn)（上）溪流 2011-01-18 23:49

@cexer
@OwnWaterloo
關于調用約定，貌似不用復制N份（VS2010下測試），函數會自動被識別為 R (__stdcall *)(...)

re: C++ 下 Function 對象的實現(xiàn)（上）溪流 2011-01-18 18:39

@zhaoyg
是的，T*自然沒問題，就是為了同時也支持傳入 T。

re: 2009-2010小結（二）溪流 2011-01-18 12:26

@潘孫友
牛逼！崇拜！

re: 2009-2010小結（二）溪流 2011-01-18 12:26

@zuhd
@right
不要瞎扯，哥很嚴肅的哦

re: 2009-2010小結（二）溪流 2011-01-18 00:47

@expter
沒有艷遇。看到有人預測數字序列的要太監(jiān)，堅決不能太監(jiān)。

re: C++ 下 Function 對象的實現(xiàn)（上）溪流 2011-01-17 12:53

@cexer
很有啟發(fā)性的提示，謝謝分享~！頂了再細讀。