Re: [問題] 關於Class指標的觀念

看板C_and_CPP作者 (我要加入劍道社!)時間10年前 (2013/08/27 22:23), 編輯推噓18(18推 0噓 158→)
留言176則, 15人參與, 最新討論串5/19 (看更多)
※ 引述《descent (「雄辯是銀，沉默是金」)》之銘言： : 但如果要得到 p (A::func() 的位址)的位址的話, : 可以使用這樣的方法： [deleted] : descent@debian-vm:tmp$ c++filt _ZZ4mainEN1A4funcEv : main::A::func() : descent@debian-vm:tmp$ ./c : p: 0x804856e : addr: 804856e : env: : debian/x86 32 bit 環境 : 我猜 printf 應該也是類似的作法, 才能正確印出 A::func() address。 咈咈咈~~果然有人踩進來了 不過實驗精神可佳 應該賞予坐墊一枚 member function pointer 的陷阱在於這個指標並不能視為一個整數 (講N次了) 我們來看一個應該會讓許多人驚訝的例子 #include <cstdio> struct A { virtual void func(); }; void A::func() {...} int main() { void (A::*p)() = &A::func; printf("addr: %p", p); return 0; } objdump + c++filt: 000000000040094c <A::func()>: 執行結果 (Debian x64 + gcc 4.7.3)： addr: 0x1 所以 A::func 的位址是 0x0000000000000001 這好像不太對 XDDDD * * * 另一個提示 struct A { void func(); }; int main() { cout << "sizeof(int*) = "<<sizeof(int*) << endl; cout << "sizeof(&A::func) = " << sizeof(&A::func) << endl; return 0; } 在我的電腦上 (Debian x64 + gcc 4.7.3) 是這樣： sizeof(int*) = 8 sizeof(&A::func) = 16 在 gcc 上，member function pointer 的大小是一般指標的兩倍呢！好開心啊 XD 事實上不同的 compiler 有非常不一樣的實作方法 有的實作和一般指標一樣大，而有的甚至占用四倍或五倍大小！ 當然，你不能把 member function pointer 當作一個整數來看 因為除了函式的位址，它還必需儲存一些額外的資訊 才能正確處理 virtual function 與多重繼承 有興趣的可以看看這篇文章 http://goo.gl/2Uc2f 所以各位應該可以理解為什麼 &A::func 不能轉成 int* 這根本是兩個世界的東西 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 202.39.238.242
推
08/27 22:27, , 1F
未看先猜 fast delegate :p
08/27 22:27, 1F
→
08/27 22:27, , 2F
我覺得小善心機有點重....
08/27 22:27, 2F
→
08/27 22:31, , 3F
我前面就好心提醒過！直接當普通指標印出來是錯的！
08/27 22:31, 3F
推
08/27 22:31, , 4F
大家快來寫cppgm
08/27 22:31, 4F
→
08/27 22:42, , 5F
不過 G 大的厲害就是會說 "那還是無號正整數阿" 不就是0跟1
08/27 22:42, 5F
推
08/27 22:44, , 6F
這是 virtual 才會發生的事情吧, 不用 virtual
08/27 22:44, 6F
→
08/27 22:44, , 7F
應該不會這樣
08/27 22:44, 7F
推
08/27 22:46, , 8F
@descent: 可是第二個沒有virtual耶?
08/27 22:46, 8F
→
08/27 22:47, , 9F
F 大大,我說的 0 與 1 跟「正整數」是無關連的,而且我也說
08/27 22:47, 9F
→
08/27 22:47, , 10F
「它會轉呼叫輸出 BOOL 型態數值」的函式,對吧?
08/27 22:47, 10F
→
08/27 22:48, , 11F
我不知道 F 大大去扭曲我說的話的用意何在?
08/27 22:48, 11F
→
08/27 22:49, , 12F
我扭曲什麼阿? 你就搞錯了. 而且我說的是你把東西都當整數
08/27 22:49, 12F
推
08/27 22:49, , 13F
virtual 比較麻煩, 要先去對付 virtual table
08/27 22:49, 13F
→
08/27 22:50, , 14F
你就搞錯了亂猜呼叫輸出 bool .現在我說整數是你把
08/27 22:50, 14F
→
08/27 22:50, , 15F
bit representation 都當做整數用.
08/27 22:50, 15F
→
08/27 22:50, , 16F
忽略型態的意涵
08/27 22:50, 16F
→
08/27 22:51, , 17F
你說我把東西都當整數,這句話就是在扭曲了.
08/27 22:51, 17F
→
08/27 22:51, , 18F
喔. 那記憶體位址為什麼是無號正整數?
08/27 22:51, 18F
→
08/27 22:52, , 19F
他不就是一堆 00001110101010 嗎
08/27 22:52, 19F
→
08/27 22:53, , 20F
我前面說了那麼多,沒想到您還是不明白
08/27 22:53, 20F
→
08/27 22:54, , 21F
對 真是蠻難明白的. 你都是影片是整數了. 我能說什麼
08/27 22:54, 21F
推
08/27 22:56, , 22F
我很好奇的是,討論記憶體的問題為何要跳 Tone 到檔案上呢?
08/27 22:56, 22F
→
08/27 22:56, , 23F
因為你就愛扯阿. 什麼是無號正整數. 你有想過他意涵嗎
08/27 22:56, 23F
→
08/27 22:56, , 24F
難道浮點數就不是無號正整數? 為什麼?
08/27 22:56, 24F
→
08/27 22:56, , 25F
這樣偏離討論主題不知道您的用意何在?
08/27 22:56, 25F
→
08/27 23:00, , 26F
那就換您說說看您的觀點如何?
08/27 23:00, 26F
→
08/27 23:05, , 27F
哪個觀點? 我都說了指標不等同無號正整數大概有數十次~
08/27 23:05, 27F
→
08/27 23:08, , 28F
然後我發現你對"無號正整數"有些跟我不一樣的認知
08/27 23:08, 28F
→
08/27 23:08, , 29F
所以我才跟你討論這個~
08/27 23:08, 29F
→
08/27 23:16, , 30F
那請問「指標不等同無號正整數」的觀點為何?
08/27 23:16, 30F
→
08/27 23:19, , 31F
我這篇文章不就在講成員函式指標不能當整數？
08/27 23:19, 31F
→
08/27 23:19, , 32F
因為他叫指標不叫無號正整數阿? 這觀點如何?
08/27 23:19, 32F
→
08/27 23:20, , 33F
還是說你覺得 &A::func 其實是個 128-bit 超大整數
08/27 23:20, 33F
→
08/27 23:20, , 34F
littleshan: 我就怕這個... (躲)
08/27 23:20, 34F
→
08/27 23:21, , 35F
天啊!原來您的理解是在於它的「型態」,而不是它的特性...
08/27 23:21, 35F
→
08/27 23:22, , 36F
所以我在前才會說您的誤會可深了...我來從沒有說它是「無號
08/27 23:22, 36F
→
08/27 23:22, , 37F
正整數型態」,沒想到您的理解跟我的不同,我終於知道了.
08/27 23:22, 37F
→
08/27 23:24, , 38F
請問哪項符合「無號非有號」的特性
08/27 23:24, 38F
推
08/27 23:30, , 39F
GNUGCC 你要不要自己回一篇告訴大家你想說啥
08/27 23:30, 39F
還有 97 則推文
→
08/29 23:23, , 137F
言下之意就是:
08/29 23:23, 137F
→
08/29 23:23, , 138F
"要轉當然可以轉阿，轉不成功只是編譯器不實作嘛 !!"
08/29 23:23, 138F
→
08/29 23:23, , 139F
以上，整理完畢，節省大家看落落長推文的時間，謝謝。
08/29 23:23, 139F
→
08/29 23:32, , 140F
幫G大找台階下好了，他在講C不是C++。
08/29 23:32, 140F
→
08/30 00:12, , 141F
我現在才知道原來有些人喜歡移花接木.
08/30 00:12, 141F
→
08/30 00:13, , 142F
W 大大,您如果不懂某些方面的理論可以看其他主題的文章.
08/30 00:13, 142F
→
08/30 00:14, , 143F
這裡是屬於程式設計討論區,不是嘴炮專用討論區.
08/30 00:14, 143F
→
08/30 00:16, , 144F
可以建議版主喜歡刻意去謀黑言論的人勿讓他再進來,以免破壞
08/30 00:16, 144F
→
08/30 00:16, , 145F
討論區的品質.
08/30 00:16, 145F
→
08/30 00:33, , 146F
......太幽默了
08/30 00:33, 146F
→
09/01 06:55, , 147F
GNUGCC 大大我想請教您對於我貼出來的 C spec 怎麼看
09/01 06:55, 147F
→
09/02 11:29, , 148F
說話啊！還是英文太難您看不懂?
09/02 11:29, 148F
推
09/03 18:36, , 149F
這種時候應該要丟個他想看的東西上來才行
09/03 18:36, 149F
→
09/03 18:37, , 150F
他不想看的東西他是怎樣都不會回應的 (像你我二人的文章)
09/03 18:37, 150F
→
09/03 18:37, , 151F
於是這裡是個他應該有興趣的東西: http://ideone.com/jBEPDT
09/03 18:37, 151F
→
09/03 18:38, , 152F
基本上這段程式所印出的就是他所想要的"指標的實際內容數"
09/03 18:38, 152F
→
09/03 18:39, , 153F
問題來了: 試解釋兩個印出 &Child::three 與 &Child::four
09/03 18:39, 153F
→
09/03 18:40, , 154F
的四個"數"究竟代表著什麼位址
09/03 18:40, 154F
→
09/03 18:40, , 155F
啊, 我的問題是對著 G 大發問的唷 ^^
09/03 18:40, 155F
→
09/04 19:45, , 156F
這些問題可以去看 descent 大大發表的討論文章,裡面都有說
09/04 19:45, 156F
→
09/04 19:46, , 157F
明,不懂理論的請以「不恥下問」的態度來發問,謝謝.
09/04 19:46, 157F
→
09/05 01:14, , 158F
所以 G 大不知道 descent 的 code 有問題. 哈哈
09/05 01:14, 158F
推
09/05 09:18, , 159F
我可以將樓樓上的發言視為你已經放棄堅持那結果是一個數嗎?
09/05 09:18, 159F
→
09/05 09:19, , 160F
那麼這便是跟你自己之前的發言自相矛盾了
09/05 09:19, 160F
→
09/05 23:08, , 161F
descent 大大的 code 我在 Visual C++ 2008 是沒問題的唷^^
09/05 23:08, 161F
→
09/05 23:09, , 162F
不過不確定其他編譯器是否有問題,不過看過了 LPH66 大大給
09/05 23:09, 162F
→
09/05 23:10, , 163F
的範例程式後發現在 Visual C++ 2008 應該是不可行,至於為
09/05 23:10, 163F
→
09/05 23:13, , 164F
什麼我想大家都知道了,如果還是不懂為何請自行發問,至於大
09/05 23:13, 164F
→
09/05 23:17, , 165F
家一直對於輸出結果倒底是什麼「數」可以去看 descent 大大
09/05 23:17, 165F
→
09/05 23:18, , 166F
使用 Visual C++ 2010 與 GCC 編譯器輸出的結果應該能推測
09/05 23:18, 166F
→
09/05 23:19, , 167F
為何輸出的結果它的「特性」會相差很大了.
09/05 23:19, 167F
→
09/05 23:22, , 168F
本人再次強調,我討論的重點是在於記憶體位址的「特性」,跟
09/05 23:22, 168F
→
09/05 23:23, , 169F
編譯器實作的技術並無直接關連,因為不管實作技術為何,CPU
09/05 23:23, 169F
→
09/05 23:26, , 170F
永遠都只使用「記憶體位址」在存取資料,各位只是看到表面上
09/05 23:26, 170F
→
09/05 23:29, , 171F
被包裝後的結果,如此而已.
09/05 23:29, 171F
推
09/05 23:33, , 172F
好吧, 看來只有你一個人站的高度不一樣而已 (攤手)
09/05 23:33, 172F
→
09/05 23:33, , 173F
這一串從頭到尾都在談 C/C++ 語言裡的指標
09/05 23:33, 173F
→
09/05 23:33, , 174F
然而我現在才終於發現原來你站的比我們討論的高度還高
09/05 23:33, 174F
→
09/05 23:34, , 175F
抽象層已經高到雲深不知處了 難怪你跟我們之間一直沒交集..
09/05 23:34, 175F
→
09/05 23:35, , 176F
嘛, 還是要說一句小心高處不勝寒啊...
09/05 23:35, 176F
‣ 更多 littleshan 的文章
文章代碼(AID): #1I7BPgaP (C_and_CPP)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 5 之 19 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共19篇)
‣ 更多 littleshan 的文章
文章代碼(AID): #1I7BPgaP (C_and_CPP)