Re: [分享] 面向對象編程從骨子裡就有問題

看板Soft_Job作者時間11年前 (2013/02/23 12:23), 編輯推噓6(6推 0噓 29→)
留言35則, 4人參與, 最新討論串8/12 (看更多)
※ 引述《mgtsai ()》之銘言： : 標題: Re: [分享] 面向對象編程從骨子裡就有問題 : 時間: Sat Feb 23 02:38:59 2013 : -- : ※ 發信站: 批踢踢實業坊(ptt.cc) : ◆ From: 114.32.58.129 : → atst2:個人認為這例子是物件責作規劃的問題, OOP也不是說一種問題 02/23 11:20 : → atst2:而光從m_worldTransform從名稱上來看,也不太像是一個object 02/23 11:23 : → atst2:應有的屬性. 我個人是認為，設計是一個整體面向的東西，光以 02/23 11:24 : → atst2:部分的設計來討論OOP的概念的極限，其實很難有一個明確結果. 02/23 11:25 : → atst2:大概最後也是各說各話吧? - -a 02/23 11:26 : → atst2:補充第二行....一種問題不會只有一種設計.. 02/23 11:28 我同意一個問題不會只有一種設計 ---------- 先回答你的 m_worldTransform 是不是屬於 Object 屬性的問題 我先前沒有把整個範例程式寫出來，而在投影片的範例中，物件會拆成一堆子物件 而整個物件，是以一大堆子物件與孫物件等等所構成的一個樹狀結構 在範例中，其中一行程式碼是： this->m_worldTransform = parentTransform * this->m_Transform; 在 computer graphics 領域 parentTransform 是指父物件整體空間中的位置與方位 m_Transform 是指子物件相對於父物件的相對位置與相對方位 兩者矩陣相乘的結果 m_worldTransform，就是子物件在整體空間中的位置與方位 而 m_worldTransform 的值最後會塞進 GPU 中將每個子物件在螢幕上畫出來 這種作法沒有太大的 argue，唯一可以說嘴的是變數名稱取得夠不夠好罷了 當整個物件在空間移動或旋轉時，會造訪整個物件樹 由最上層的根物件一層一層利上述算式計算出每個子物件 m_worldTransform 所以，m_worldTransform 代表某個特定時刻子物件在空間中的位置與方位 在概念上屬於子物件的屬性，本身沒有太大的問題 ---------- 當然，一個問題不會只有一種設計，只是在 performance incentive 的部分 像範例中要計算每個子物件在空間中的位置與方位 資料面的結構設計所造成的 performance impact 太大 以致於我們得要重新檢視原本的純 OOP 寫法是否洽當的問題 投影片的作者在裡頭推銷 Data Oriented (DO) 的觀念，有別於一般的 OO 好不好用我自己不予評論，但至少在那裡頭點出了另一種架構設計的思維 在 performance incentive 的部分，資料本身的結構設計應擺在 OO 之前 結構定型了之後，再考慮如何包裝成 OO 我是建議先花點耐性看完整個投影片，會更清楚作者的論述 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 122.116.84.29 ※ 編輯: mgtsai 來自: 122.116.84.29 (02/23 15:11)
推
02/23 15:44, , 1F
受教了:) 感謝
02/23 15:44, 1F
推
02/23 20:32, , 2F
真實世界本來就不完美,效率的問題,C++有不足C的地方,C也
02/23 20:32, 2F
→
02/23 20:33, , 3F
有不足asm的地方,要在真實世界裡打滾,就只能機靈點,隨時
02/23 20:33, 3F
→
02/23 20:34, , 4F
依照遇到的問題改變做法,至少.cc裡可以用C/ASM,.c裡只能
02/23 20:34, 4F
→
02/23 20:36, , 5F
用C/ASM,.s裡卻只能用ASM,先用C++支撐整個framework最好
02/23 20:36, 5F
→
02/24 00:15, , 6F
abcdefghi 的問題只要懂 linking 就能解決, 跟你附檔
02/24 00:15, 6F
→
02/24 00:15, , 7F
名用什麼一點關係也沒有
02/24 00:15, 7F
→
02/24 00:16, , 8F
所以你的意思是如果一個 project 是用純c 寫得, 他就
02/24 00:16, 8F
→
02/24 00:16, , 9F
不能用到 c++ 的 library 嗎? 賣鬧阿
02/24 00:16, 9F
推
02/24 01:16, , 10F
abcdefghi說得沒錯 .c裡是c/asm...link c++ 也是link
02/24 01:16, 10F
推
02/24 01:19, , 11F
c 只是這個c wrapper可以轉呼叫c++
02/24 01:19, 11F
→
02/24 04:25, , 12F
你所謂的inline assembly跟本就不是標準，是compiler
02/24 04:25, 12F
→
02/24 04:26, , 13F
提供的語法延伸，不需要把.cc裡面可以放c/c++/asm說
02/24 04:26, 13F
→
02/24 04:27, , 14F
的像是c++這個語言的恩賜
02/24 04:27, 14F
→
02/24 04:30, , 15F
micola可以先去查extern ＂C",name mangling的資料
02/24 04:30, 15F
→
02/24 04:31, , 16F
你的.c檔，.cc檔從linker的角度根本一點意義也沒有
02/24 04:31, 16F
→
02/24 04:32, , 17F
都是obj,只是symbol的差異而已
02/24 04:32, 17F
推
02/24 10:53, , 18F
不管inline asm是不是標準,但目前市面上的C++ compiler
02/24 10:53, 18F
→
02/24 10:54, , 19F
都有支援,發生有效率的問題,critical的部份一定是集中到
02/24 10:54, 19F
→
02/24 10:58, , 20F
同一個檔案來處理,在C的程式裡要呼叫C++,還得在C++程式
02/24 10:58, 20F
→
02/24 11:00, , 21F
包裝一層C API才能用,在C++裡呼叫C API根本沒這個問題,
02/24 11:00, 21F
→
02/24 11:03, , 22F
扯到linker真是扯太遠了,硬把symbol resolve掉,register
02/24 11:03, 22F
→
02/24 11:04, , 23F
裡的值是錯的,有什麼意義?
02/24 11:04, 23F
→
02/24 23:24, , 24F
register的值是錯的是calling convention的問題
02/24 23:24, 24F
→
02/24 23:25, , 25F
照你所謂的全部寫成.cc只要不同檔案用不同calling
02/24 23:25, 25F
→
02/24 23:25, , 26F
convention的編譯器編譯也會有此問題
02/24 23:25, 26F
→
02/24 23:26, , 27F
不需要把他扯進來,事實上 extern "C" 在同一個
02/24 23:26, 27F
→
02/24 23:26, , 28F
compiler 體系下差別往往只是name mangling
02/24 23:26, 28F
→
02/24 23:26, , 29F
所以講到linker一點都不為過
02/24 23:26, 29F
→
02/24 23:27, , 30F
事實上你的說法就是把C認為是C++的子集,所以我用C++
02/24 23:27, 30F
→
02/24 23:27, , 31F
寫我超強的方式在思考
02/24 23:27, 31F
→
02/24 23:27, , 32F
但其實不是,去看看VLA吧,他只是C++ 的condition
02/24 23:27, 32F
→
02/24 23:28, , 33F
feature, 你用這種方式去選擇語言根本就是搞笑
02/24 23:28, 33F
推
02/25 00:12, , 34F
亂扯一通,你喜歡用C linking C++的方式,隨你便吧!光看到
02/25 00:12, 34F
→
02/25 00:12, , 35F
"我用C++寫我超強的方式在思考" 就完全不想理你了!
02/25 00:12, 35F
‣ 更多 mgtsai 的文章
文章代碼(AID): #1HA4GsHo (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 8 之 12 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共12篇)
‣ 更多 mgtsai 的文章
文章代碼(AID): #1HA4GsHo (Soft_Job)