1樓：zr scat
類似於c語言函式指標的做法，在某種程度上，可以達到類似的效果（實際上lamada比c的函式指標更靈活一點，畢竟還可以直接bind上下文）。
某些情況下，用繼承是更直觀的，比如裝飾模式下對繼承的使用。而在gui開發裡對不同控制項的派生是可以很直觀的使用裝飾模式的。
2樓：青禾紀
這個東西在C++11之前就有了吧，只是C+11才加入標準我的回答就是完全可以取代，effective C++ Item35: Consider alternatives to virtual functions.
3樓：
我是delphi出身的，std::function給我第一眼的感覺就是這玩意拿來實現事件機制極棒，所以這兩個就是事件和繼承的區別啊，應用場合不同沒有誰好誰壞。
不過我寫庫時都是同時用的，具體是:虛函式優先順序高，先呼叫虛函式(即類內的事件處理函式)，虛函式返回真表示此事件已被虛函式handle，處理結束;反之則繼續呼叫繫結的std::function(即類外的事件處理函式)。
這樣的話，使用者可以根據具體情況和方便程度選擇繼承和事件用哪個。
4樓：wp zh
1.如果做乙個GUI框架,到處這樣做,行不行?
行。2.從語言的角度,這樣是否比虛函式的方式更好?
好。如果僅僅為了override乙個onclick，而繼承乙個button的話，實在是浪費。繼承就是這樣想要的不想要的一股腦全給你了。
所謂的耦合也就產生了。這裡如果把onclick的處理做成乙個基類clickprocer，然後包含進button，通過button來動態管理clickprocer，我覺得才是繼承真正發揮威力的地方。反之看function，基本上沒有那麼強的耦合，清晰、靈活而沒有任何負擔。
2.面對某些需求,比例GUI框架,這樣做和虛函式哪個更好?
我覺得可能是2者的組合會比較好一些。
3.如果這樣更好,為什麼市面上的大部分GUI庫都不是這種形式? 畢竟C++11也出來幾年了,沒道理不跟進啊.
庫的開發可以在內部實現用各種奇技淫巧，c++11也正是為這種內部實現提供了更多的功能。但是對外暴露的介面還是要盡可能保持簡潔和相容性。大眾一點的庫還是要考慮編譯器的支援的，小眾一點的庫也有這種方式實現的。
5樓：賈凡
個人淺見。繼承首先想到兩個用途。子類可以實現，也可以不實現。
如果用std::function的話，豈不是都要實現（如果呼叫乙個公共函式會破壞封裝型吧）？第二是，繼承還有一部分功能是多型，這個多型起來似乎有點困難。
不過閉包的概念還是很先進的，配合繼承使用效果應該很好。
6樓：
你這個如何處理父類也要對該訊息做一些處理的情況
建議模仿C#的WinForm，C++裡面可以使用fastdelegate庫
C 虛函式和C 虛函式的區別？
c 不了解。但是關於c 的說法，這樣是不對的。題主你其實糾結的不是語言，而是an implementation of c 意思是，之所以會有上面的結果，是因為你的編譯器的實現。在c 標準裡面，對於virtual 的具體實現沒有做任何要求。而virtual method table只是大多數編譯器的實...
請問虛繼承，虛函式和虛指標（vptr）之間有什麼關係？（具體問題見描述）？
阿翔 首先建議你看完inside C Object model第四章對於你理解虛函式虛繼承有很大幫助 其次，你最好明確一下，你問的虛指標vptr指的什麼，vptr常指的是vfptr，用於實現虛函式的功能，指向虛表，而還有乙個vbptr，用於實現虛繼承，指向乙個偏移量表 vfptr與vbptr各佔乙個...
建構函式不能是虛函式
ylq 建構函式不是不能是虛函式，而是完全沒意義。c 在編譯期間就能確定你要建立的物件的具體型別，而這個具體型別包含了什麼，繼承了什麼在編譯期間也是明確的，所以要構造什麼也都是明確的，根本沒必要存在虛建構函式。虛函式的存在是因為編譯期間沒法確定具體呼叫物件，才會有虛函式，虛函式表這麼個東西。 雞賊軒...