※ 引述《HZYSoft.bbs@ptt.cc (PCMan 2004)》之銘言：
> 其實通常不一定是這麼回事，也未必有 overhead
是的，這種 size 上的 overhead 「未必」會發生，
然而目前大多數的編譯器在 class 本身狀況複雜時幾乎會有 overhead，
目前我手上沒有 MSVC 編譯器，
但依經驗和印象來說 MSVC 在多重和虛擬繼承的情形，
並無法避開 member function size overhead 的發生，
這可能需要請有 MSVC 編譯器的人實驗看看。
> 在 inline 的時候可以避免 overhead，且就算沒 inline 不見得比較慢
在使用 member function pointer 時，
和 function object（或稱 functor）的 operator() 可被 inline 情形不同，
由於無法確定會 bind 的對象，
只要有點複雜的程式就會造成無法 inline 的狀況，
幾乎沒有 inline 的可能性。
> 以下舉相當常用的 Visual C++ 為例
> member function 和 一般的 static function 其 pointer 大小完全一樣
寫到這裡，我特地用 google 搜尋了一下，
您可以參考看看 http://www.codeproject.com/cpp/FastDelegate.asp，
裡面的 Implementations of Member Function Pointers 段落中有一張表，
若其內容為真，您可能要重新考慮一下如此肯定的說法是否有問題。
> 差別只在 calling convention，一個是 C 的 calling convention
> 另一個是 this call，也就是 call 的時候把 this pointer 放入 ECX register
> 其實這效果跟 fast call 相當類似，function pointer 本身和 static function 無異
> void gtk_window_set_title(register GtkWindow* window, gchar* title);
> void GtkWindow::set_title(gchar* title);
> 上面兩行實際執行的效果和 overhead 基本上完全一樣，而早期的 C 不能 inline
> 所以 C++ 有時不但不會比較慢，而且經常能略勝 C 一籌
> 一般來說 Getter 和 Setter function 都會寫成 inline，無 overhead
> C++ 的 function 會有 overhead 的地方主要在 virtual function，
> 而非所有 member function 都會，事實上大多 member function 和 C 沒差
> 以上雖然沒有明文規範，但是編譯器基本上不會選擇用比較有 overhead 的方式實做
這部分的爭議倒是比較不那麼大。
> 這些東西教授不知道很正常，換一個好的演算法往往勝過你省下上千個 overhead
> 研究演算法的人不需計較這種實做細節，那對他們沒有意義。
這牽涉到我第一篇回文的重心，您可能沒有注意到，
就是原發文者說在學校學不到東西，
而我列出一些原因告訴原發文者不應該期待學校會教什麼，
然後列出一些教授誤人子弟的言論。
另外，通常教 C++ 語言這門課的教授不應該是專門做演算法的，
因為「程式語言」和「程式設計」這兩門課並不適合這類教授進行教學，
除非是年輕時代對 C++ 很有興趣之後才轉型走向演算法的老教授，
但依 C++ standard 制訂的年代來說，這種老教授應該不存在。
再來，會被此類 overhead 拖累的演算法一般來說不是偏重效能考量，
而是偏重空間使用考量，這也是近幾年來新興的論文題目之一，
由於記憶體容量越來越大，對 PC 以上等級的系統研究節省記憶體意義已經不大，
很多論文已經轉向記憶體受限環境下如何節省空間的使用，
譬如現在被台灣政府炒到翻的嵌入式系統與 SoC 設計裡的軟體部分，
這類 overhead 常在研究生要跑數據丟 paper 前才被注意到，
不少例子是為了畢業在論文數據上動手腳，
國外倒是會有老實招認然後投去 conference 的情形。
上面兩段是分別就教育面和學術研究價值面做探討，
最後這裡就是實務面的考量了，
一般來說 C++ 程式除了 OOP 外還注重一般化（也就是 generic），
為求避免發生「寫死」的情形，
聽信或教人「xxxxx 的 size 在 xxx 一定是 xxxx bytes」是很不好的，
我曾經看過有人製作 pointer 容器時，
使用一般 function pointer size 初始化每個元素的大小，
然後試圖將 member function pointer 和一般 function pointer 塞在一起，
這位仁兄後來的確用很奇怪的方式達到他的目的了，
不過很遺憾的是之後他拿去別的平台無法編譯他的程式。
至於為何要做 pointer 容器？印象中是為了實作 thread manager...
後來這位仁兄看到 C# 的問世以及 delegate 的到來，
快樂的棄 C++ 投向 C# 的懷抱當中...
又，如果希望能夠充分發揮 C++ 的所有威力而又毫無阻礙，
我個人建議是使用 Comeau C++，雖然它要錢（可是不貴），
GCC 目前在 4.1 版重寫了 C++ parser，試圖將 template 的支援做得更好，
GCC 至今仍然毫無計畫實現 export 的功能，
MSVC 的狀況我不清楚，事實上我幾乎沒有用過 MSVC 寫過 C++ 程式。
--
Name: Tseng, Ling-hua E-mail Address: uranus@it.muds.net
School: National Chung Cheng University
Department: Computer Science and Information Engineering
Researching: Porting GCC and Implementing VLIW instruction scheduler in GCC
Homepage: https://it.muds.net/~uranus
--
╔═══╗ ┼────────────────────────╮
║狂狷 ║ │＊ Origin：[ 狂 狷 年 少 ] whshs.cs.nccu.edu.tw ╰─╮
║ 年少║ ┼╮ < IP：140.119.164.16 > ╰─╮
╚╦═╦╝ ╰ ＊ From：218-171-156-105.dynamic.hinet.net
─╨─╨─ ＫＧＢＢＳ ─ ◎ 遨翔"BBS"的狂狷不馴；屬於年少的輕狂色彩 ◎